同时调用同一个函数：死锁是如何发生的？

Question

new_customerWeb 应用程序每秒调用我的函数数次（但每个会话仅调用一次）。它所做的第一件事就是锁定customer表（执行“如果不存在则插入”—— 的一个简单变体upsert）。

我对文档的理解是，其他调用new_customer应该简单地排队，直到所有先前的调用都完成：

LOCK TABLE 获得一个表级锁，必要时等待任何冲突的锁被释放。

为什么有时会死锁？

定义：

create function new_customer(secret bytea) returns integer language sql 
                security definer set search_path = postgres,pg_temp as $$
  lock customer in exclusive mode;
  --
  with w as ( insert into customer(customer_secret,customer_read_secret)
              select secret,decode(md5(encode(secret, 'hex')),'hex') 
              where not exists(select * from customer where customer_secret=secret)
              returning customer_id )
  insert into collection(customer_id) select customer_id from w;
  --
  select customer_id from customer where customer_secret=secret;
$$;

日志中的错误：

2015-07-28 08:02:58 BST 详细信息：进程 12380 等待数据库 12141 的关系 16438 上的 ExclusiveLock；被进程 12379 阻止。
        进程12379在数据库12141的关系16438上等待ExclusiveLock；被进程 12380 阻止。
        进程 12380：选择 new_customer(decode($1::text, 'hex'))
        过程 12379：选择 new_customer(decode($1::text, 'hex'))
2015-07-28 08:02:58 BST 提示：有关查询详细信息，请参阅服务器日志。
2015-07-28 08:02:58 BST 上下文：SQL 函数“new_customer”语句 1
2015-07-28 08:02:58 BST 声明：选择 new_customer(decode($1::text,'hex'))

关系：

postgres=# select relname from pg_class where oid=16438;
????????????
? relname  ?
????????????
? customer ?
????????????

---

编辑：

我设法获得了一个简单的可重现测试用例。对我来说，由于某种竞争条件，这看起来像是一个错误。

架构：

create table test( id serial primary key, val text );

create function f_test(v text) returns integer language sql security definer set search_path = postgres,pg_temp as $$
  lock test in exclusive mode;
  insert into test(val) select v where not exists(select * from test where val=v);
  select id from test where val=v;
$$;

bash 脚本在两个 bash 会话中同时运行：

for i in {1..1000}; do psql postgres postgres -c "select f_test('blah')"; done

错误日志（通常是 1000 次调用中的一些死锁）：

2015-07-28 16:46:19 BST ERROR:  deadlock detected
2015-07-28 16:46:19 BST DETAIL:  Process 9394 waits for ExclusiveLock on relation 65605 of database 12141; blocked by process 9393.
        Process 9393 waits for ExclusiveLock on relation 65605 of database 12141; blocked by process 9394.
        Process 9394: select f_test('blah')
        Process 9393: select f_test('blah')
2015-07-28 16:46:19 BST HINT:  See server log for query details.
2015-07-28 16:46:19 BST CONTEXT:  SQL function "f_test" statement 1
2015-07-28 16:46:19 BST STATEMENT:  select f_test('blah')

---

编辑2：

@ypercube建议变体与lock table外的函数：

for i in {1..1000}; do psql postgres postgres -c "begin; lock test in exclusive mode; select f_test('blah'); end"; done

有趣的是，这消除了死锁。

Answer 1

我将此发布到 pgsql-bugs并且Tom Lane的回复表明这是一个锁升级问题，被 SQL 语言函数处理方式的机制所掩盖。本质上，生成的锁是在表上的排他锁之前insert获得的：

我相信这个问题是一个 SQL 函数会立即解析整个函数体（可能也计划；现在不想检查代码）。这意味着由于 INSERT 命令，您在函数体解析期间在“测试”表上获取 RowExclusiveLock，在 LOCK 命令实际执行之前。因此 LOCK 表示锁升级尝试，并且会出现死锁。

这种编码技术在 plpgsql 中是安全的，但在 SQL 语言函数中则不然。

已经讨论过重新实现 SQL 语言函数，以便每次解析一个语句，但不要对在那个方向发生的事情屏住呼吸；对任何人来说，这似乎都不是一个高度优先的问题。

问候，汤姆·莱恩

这也解释了为什么在包装的 plpgsql 块中锁定函数外部的表（如@ypercube所建议的）可以防止死锁。