在 SELECT 中嵌入 pg_advisory_lock 与显式使用另一个语句有什么好处？答案

【问题标题】：What is the benefit of embedding pg_advisory_lock inside SELECT vs explicitly using another statement?在 SELECT 中嵌入 pg_advisory_lock 与显式使用另一个语句有什么好处？
【发布时间】：2017-09-14 20:36:17
【问题描述】：

我无法真正理解https://www.postgresql.org/docs/9.1/static/explicit-locking.html的例子

他们将锁与 SELECT 子句一起嵌入的位置 SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok

它从FOO 中选择了什么？如果是这样的话我会更好理解

SELECT pg_advisory_lock(123); //lock
SELECT * FROM foo WHERE id = 12345;

它显式锁定块的位置。我似乎无法在任何地方找到关于如何真正使用咨询锁的解释来解释嵌入和显式之间的区别。

【问题讨论】：

标签： sql postgresql

【解决方案1】：

执行SELECT pg_advisory_lock(123); 将在123 上创建一个锁，无论它是否为有效值。仅当表 foo 中有 ID 123 的条目时，执行SELECT pg_advisory_lock(id) FROM foo WHERE id = 123; 才会创建锁。

让我们注意在pg_locks doc 中找到的那一行：

按键的实际含义由用户决定

这倾向于暗示 select/from/where 语法用于将锁关联到现有行，而单独的 select 语法用于更广泛的含义，例如应用程序范围的锁。

【讨论】：