红移可能出现死锁

Posted 2023-03-31

【中文标题】红移可能出现死锁

【英文标题】：Possible deadlock in redshift

【发布时间】：2019-08-01 23:54:16

【问题描述】：

我有两个似乎相互阻塞的红移查询，所以我怀疑可能存在死锁

query1 是 ETL 管道中的查询

DROP TABLE IF EXISTS temp_table;
CREATE TABLE temp_table AS SELECT * FROM sometable;
BEGIN;
ALTER TABLE table_a RENAME TO temp_old_table;
ALTER TABLE temp_table RENAME TO table_a;
END;
DROP TABLE IF EXISTS temp_old_table;

query2 是即席查询；

select * from table_a;

query1 和 query2 同时运行。不确定哪个查询首先运行。但无论出于何种原因，两个查询都卡住了。 这是 pg_locks 中的锁定情况： query2 在 table_a 上有 AccessShareLock，授予 true query1 正在等待 table_a 上的 AccessExclusiveLock，授予 false

由于 query2 已经有 AccessShareLock，它应该能够继续前进，并且 query1 也应该完成。

看起来可疑的地方是 query1 不是单个事务。它可能会尝试多次获取锁，而 query2 可能会在两者之间获取锁。这两个查询之间是否有可能发生死锁的情况？

【问题讨论】：

很奇怪，纯SELECT 查询获得了锁。 Query2 是如何运行的，是通过 SQL 客户端吗？它有自动提交选项吗？

【参考方案1】：

来自How to Prevent Locks from Blocking Queries in Amazon Redshift：

AccessShareLock：在 UNLOAD、SELECT、UPDATE 或 DELETE 操作期间获得。 AccessShareLock 仅阻止 AccessExclusiveLock 尝试。 AccessShareLock 不会阻止其他试图在表上读取或写入的会话。

当一个表获得一个锁时，锁会一直存在，直到您使用 COMMIT 或 ROLLBACK 完成事务。等待锁的事务可以阻塞也等待获取相同锁的后续事务。这可能会导致集群上的锁排队。

奇怪的是SELECT 会导致阻塞。

如果您使用的是 SQL 客户端，请打开自动提交。

【讨论】：

这是来自 aws 支持的响应。所以你的猜测是对的。谢谢！ So what this looks like to me is that one of your users, through their SQL client (SQL workbench/j possibly), initiates a connection with AUTOCOMMIT off which causes all queries executed in a manual commit mode, and the locks on the resources will not be released unless the transaction is closed.