这种互斥量实现在PostgreSQL中有意义吗?

时间:2019-03-20 17:44:57

标签: postgresql synchronization mutex

我需要在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 个答案:

答案 0 :(得分:1)

不,我会做不同的事情。

问题是您需要继续轮询该锁,这意味着不必要地浪费了CPU时间或等待时间超出了必要。

此要求非常适合PostgreSQL的advisory locks

您可以选择一个锁号,而不是像Singleton这样的锁名。 1234。

要获取锁,请运行

SELECT pg_advisory_lock(1234);

要释放锁,请运行

SELECT pg_advisory_unlock(1234);

这与正常的数据库锁一样,通过在锁不可用时挂起调用过程并在锁持有者释放锁后立即恢复调用过程来工作。还有一些功能可以“轮询”咨询锁以确保可用性而不被阻塞。

这些锁与PostgreSQL的事务无关,它们会一直保留到释放或数据库会话结束为止(因此,没有“孤立锁”的危险)。

这些锁也不会干扰自动真空操作。

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