这种互斥锁实现在 PostgreSQL 中有意义吗？答案

【问题标题】：Would this mutex implementation make sense in PostgreSQL?这种互斥锁实现在 PostgreSQL 中有意义吗？
【发布时间】：2019-08-11 12:32:36
【问题描述】：

我需要在 PostgreSQL 中实现数据库会话之间的同步。

在 SQL Server 中，我将通过创建自己的“锁定”表来实现它。

Create table MyLock(LockName VARCHAR(100) NOT NULL UNIQUE, LockOwner INT NULL)

我不使用显式事务来避免真正锁定事情，我会通过将我的会话 ID 设置为“所有者”来获取我的“单例”锁。

UPDATE MyLock
  SET LockOwner = *MySessionId*
  WHERE LockName = 'Singleton' 
  AND LockOwner IS NULL;

通过不使用显式事务，我不会阻止其他进程。您可以将其视为“软锁”...

如果我的更新成功，那么我知道我“拥有”了锁，我可以处理一些代码，而其他人会等待。如果我的更新没有更新，我知道其他人有“锁定”，我等待或放弃。

我需要在 PostgreSQL 中实现类似的东西。

你会这样做吗？

【问题讨论】：

【解决方案1】：

不，我会做不同的。

问题是您需要不断轮询锁，这意味着不必要地浪费 CPU 时间或比必要的等待时间更长。

这个要求非常适合 PostgreSQL 的advisory locks:

您选择一个锁号，而不是像Singleton 这样的锁名称，例如1234.

要获得锁，运行

SELECT pg_advisory_lock(1234);

要释放锁，运行

SELECT pg_advisory_unlock(1234);

这就像普通的数据库锁一样，如果锁不可用则暂停调用进程，并在锁持有者释放锁后立即恢复它。还有一些功能可以在不阻塞的情况下“轮询”咨询锁的可用性。

这些锁独立于 PostgreSQL 的事务，它们一直保持到释放或数据库会话结束（因此不存在“孤立锁”的危险）。

这些锁也不会干扰 autovacuum 操作。

如果应用程序想要使用数据库技术进行同步，这是一个完美的工具。

【讨论】：