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

Question

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

它们与SELECT子句一起嵌入锁定SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok

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

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

它显式锁定块的位置。 我似乎无法找到解释如何在任何地方真正使用咨询锁定来解释嵌入和明确地在其自己的陈述之间的差异。

Answer 1

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

让我们注意pg_locks文档中的行 ：

密钥的实际含义取决于用户

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