Question

我写了一个简单的存储过程：

CREATE OR REPLACE FUNCTION "public"."update_table01" (
    int4, -- $1 (population)
    int2 -- $2 (id)
) RETURNS "pg_catalog"."void" AS
$body$
BEGIN
    UPDATE "table01"
    SET
            population = $1
    WHERE id = $2;
END;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;

我在我的Java服务器（jre7）中调用它，我正在使用Hibernate 4和C3P0作为我的连接池。这是在PostgreSQL 9.2.4上执行的。我有一个对应于table01的Hibernate实体（由注释映射），我指定此过程用作SQL更新：

@SQLUpdate(sql = "{call update_table01(?, ?)}", callable = true)

当我使用多个线程（大约20-30个）进行负载测试时经常调用它，发生了一些死锁，这让我大吃一惊。以下是日志的相关部分：

2013-08-14 14:51:19 CEST [23495]: [3-1] LOG:  process 23495 detected deadlock while waiting for ShareLock on transaction 140127434 after 1000.048 ms
2013-08-14 14:51:19 CEST [23495]: [4-1] STATEMENT:  update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23495]: [5-1] ERROR:  deadlock detected
2013-08-14 14:51:19 CEST [23495]: [6-1] DETAIL:  Process 23495 waits for ShareLock on transaction 140127434; blocked by process 23481.
Process 23481 waits for ShareLock on transaction 140127431; blocked by process 23495.
Process 23495: update table01 set population=$1 where id=$2
Process 23481: update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23495]: [7-1] HINT:  See server log for query details.
2013-08-14 14:51:19 CEST [23495]: [8-1] STATEMENT:  update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23481]: [3-1] LOG:  process 23481 still waiting for ShareLock on transaction 140127431 after 1000.086 ms
2013-08-14 14:51:19 CEST [23481]: [4-1] STATEMENT:  update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23481]: [5-1] LOG:  process 23481 acquired ShareLock on transaction 140127431 after 1000.227 ms
2013-08-14 14:51:19 CEST [23481]: [6-1] STATEMENT:  update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23938]: [3-1] LOG:  process 23938 still waiting for ExclusiveLock on tuple (8,72) of relation 16890 of database 16751 after 1000.119 ms
2013-08-14 14:51:19 CEST [23938]: [4-1] STATEMENT:  update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23938]: [5-1] LOG:  process 23938 acquired ExclusiveLock on tuple (8,72) of relation 16890 of database 16751 after 1000.174 ms
2013-08-14 14:51:19 CEST [23938]: [6-1] STATEMENT:  update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23520]: [3-1] LOG:  duration: 970.319 ms  execute <unnamed>: update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23520]: [4-1] DETAIL:  parameters: $1 = '5731', $2 = '294'
2013-08-14 14:51:19 CEST [23481]: [7-1] LOG:  duration: 1000.361 ms  execute <unnamed>: update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23481]: [8-1] DETAIL:  parameters: $1 = '1586', $2 = '253'
2013-08-14 14:51:19 CEST [23524]: [3-1] LOG:  duration: 531.909 ms  execute <unnamed>: update table01 set population=$1 where id=$2
2013-08-14 14:51:19 CEST [23524]: [4-1] DETAIL:  parameters: $1 = '1546', $2 = '248'
2013-08-14 14:51:19 CEST [23938]: [7-1] LOG:  duration: 1004.863 ms  execute <unnamed>: update table01 set population=$1 where id=$2

我不善于解释Postgres日志，所以如果我错了，请纠正我。我认为这说明两个进程最终陷入僵局。两人都在执行相同的声明。

很多东西让我很困惑。最重要的是：我不明白当存储过程中只获得具有该特定ID的行的单个行级锁时，两个进程（甚至更新不同的行）如何最终陷入死锁？这是更改此表的唯一过程。是不是应该获得一个独占锁（执行SELECT ... FOR UPDATE时相同）？ ShareLocks来自哪里？在后面的行（23938）中显示的是什么过程？我最好的猜测是23938也在等待锁定，当23495被杀时，它获得了锁定。

然后我尝试了以下内容：

CREATE OR REPLACE FUNCTION "public"."update_table01" (
    int4, -- $1 (population)
    int2 -- $2 (id)
) RETURNS "pg_catalog"."void" AS
$body$
BEGIN
    PERFORM 1 FROM "table01" WHERE id = $2 FOR UPDATE;

    UPDATE "table01"
    SET
            population = $1
    WHERE id = $2;
END;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;

当我再次运行时，我无法重现它。没有更多的僵局。

为什么会这样？

编辑：经过一段时间的调查，似乎Hibernate在刷新会话时有时会自行调用此方法。在某些情况下，对于不同的实体，在同一事务中都有好几次。这可能会导致死锁，因为每次调用update_table01（）都会使用FOR UPDATE锁定特定的table01列行。通过一些不正确的呼叫排序，它可以创建一个循环等待。在我使这个实体不可更新（即用update = false标记所有列）之后，一切正常。现在，我对这种Hibernate行为感到非常惊讶，因为RAM中的table01实体没有附加到任何负责以后事务的会话。然而，Hibernate将这些实体刷新到数据库，我不知道为什么。

至于锁，我已经确定了我的另外两个存储过程，它们插入/更新到引用table01的其他一些表（其中一个更改了FK列）。这些将在table01中的相应FK行上请求ShareLock，因此将与update_table01（）冲突。所以这三个存储过程将等待彼此完成。仅此一项不能创建循环等待，但是如果在调用这些存储过程之后向update_table01（）添加了几个Hibernate引起的调用，则可以实现。

Answer 1

首先，你看到的排他锁：

ExclusiveLock on tuple (8,72) of relation 16890 of database 16751

这应该是你的“table01” - 试试：

SELECT * FROM pg_class WHERE oid = 16890;

其次，是的，你有进程23495和23481互相阻塞。 PostgreSQL在等待1秒后检测到这一点并取消23495.然后，在1000.361ms之后，进一步下行23481的几行。

要测试这个，你需要打开两个终端，每个终端运行psql。这样你就可以控制每个中的暂停。在每个终端中发出BEGIN并尝试在两个终端中运行更新。看看pg_locks视图，看看发生了什么。

我的实验都没有能够重现这一点，我看不出它是怎么回事。

您看到的ShareLock可能是在UPDATE发生时阻止对表进行更改的那个。您不希望有人丢弃您要更新的列。

当然，两个共享锁can't conflict因此必须有其他工作。

从您的日志摘录中发现的是，您有许多其他简单的更新，这些更新都是为了这么简单的更新而花费很长时间。

死锁检测器可能是错误的 - 您的服务器处于极端负载状态，并且您的两个事务之间没有冲突。如果您的deadlock_timeout设置有点长，则可能永远不会发生。

更新单行的简单PL / pgsql存储过程中的死锁（由Hibernate调用）

1 个答案: