什么时候"选择更新"锁定和解锁?

ven*_*s.w 17 database postgresql locking

这是我的伪代码:

re = [select **result** from table where **condition**=key for update]

if[re satisfies]
{
    delete from table where **condition** = key;
}

commit
Run Code Online (Sandbox Code Playgroud)

我想询问条件是否等于"key"的行是否已被删除,"select for update"阻止的锁是否可以自动解锁,这意味着如果此时另一个进程进入并选择相同的"密钥" "它不能被这个阻挡?

Cra*_*ger 23

锁定是在命令执行期间(通常在开始时或接近开始时)进行的.锁定(咨询锁除外)在事务提交或回滚时释放.没有FOR UNLOCK,也没有UNLOCK命令来反转表级LOCK命令的效果.这一点都在PostgreSQL文档的并发控制部分中进行了解释.

您必须提交或回滚事务以释放锁.

此外,询问"此行已被另一个并发事务删除"并没有任何意义.在删除行提交的事务提交之前,它并没有真正删除...即便如此,它可能已被删除并重新插入行或另一个并发事务可能会再次插入行.

您是否正在构建任务队列或消息队列系统,因为如果是这样,那个问题就解决了,您不应该尝试重新发明那个异常复杂的轮子.请参阅PGQ,ActiveMQ,RabbitMQ,ZeroMQ等.(未来PostgreSQL版本可能包括FOR UPDATE SKIP LOCKED正在测试,但在撰写时尚未发布).

我建议您发布一个新问题,其中包含您要解决的潜在问题的更详细说明.您假设您的问题的解决方案是"找出该行是否已被删除"或"解锁该行".这可能实际上不是解决方案.这有点像有人说"我在哪里买汽油"当他们的推车没有去,所以他们认为它没有燃料.燃料不是问题,问题是推自行车不需要加油,你必须踩下它们.

解释背景.解释你想要实现的目标.最重要的是,不要发布伪代码,发布您遇到问题的实际代码,最好是以自包含和可运行的形式发布.

  • 这是一个旧答案,从第 9 页开始,值得一提的是,PostgreSQL 已经包含“FOR UPDATE SKIP LOCKED”很长一段时间了,并且“SKIP LOCKED”非常适合使用队列。 (5认同)