PostgreSQL中的读取提交隔离级别是否会发生更新丢失？

Question

我有一个查询如下在PostgreSQL：

UPDATE 
     queue 
SET 
  queue.status   = 'PROCESSING' 
WHERE 
    queue.status   = 'WAITING' AND
    queue.id       = (SELECT id FROM queue WHERE STATUS = 'WAITING' LIMIT 1 )
RETURNING 
        queue.id

许多工作人员试图一次处理一项工作（这就是为什么我有限制为1的子查询）。在此更新之后，每个工作人员都会获取有关id的信息并处理工作，但有时他们会获取相同的工作并处理两次或更多次。隔离级别已读提交。

我的问题是，我如何保证一个工作将被处理一次？我知道有这么多的帖子，但我可以说我已经尝试了其中的大部分，但都没有帮助（）；

• 我已尝试选择更新，但它导致了死锁的情况

任何帮助都将不胜感激。

Answer 1

跳过锁定可用于在PostgreSql中实现队列。看见

Answer 2

在您描述的情况下不会发生丢失的更新，但它也不会正常工作。

在上面给出的示例中，如果（假设）10个工人同时启动，所有10个工人都将执行子查询并获得相同的ID。他们都将尝试锁定该ID。其中一个工人将成功；其他人会堵住第一个人的锁。一旦第一个后端提交或回滚，其他9个后端将争夺锁。您将获得它，重新检查WHERE子句，并查看queue.status测试不再匹配，然后返回而不修改任何行。其他8个也会发生同样的情况。因此，您使用了10个查询来完成一个查询的工作。

如果您未能明确检查更新结果，并看到零行更新，您可能会认为更新丢失，但事实并非如此。由于对执行顺序和隔离规则的误解，您的应用程序中出现了一个并发错误。真正发生的一切是，您正在有效地序列化后端，以便一次只有一个后端真正取得进展。

PostgreSQL避免让它们都获得相同队列项ID的唯一方法是序列化它们，因此直到查询#1完成，它才开始执行查询#2。如果需要，可以通过LOCKing队列表来实现这一点...但是同样，您也可以只使用一个辅助角色。

你不能用咨询锁来解决这个问题，无论如何都不容易。在获得第一个可锁定项之前，使用非阻塞锁定尝试迭代队列的黑客操作会有效，但会缓慢而笨拙。

您正在尝试使用RDBMS实现工作队列。这样做不好。这将是缓慢的，它将是痛苦的，而且要做到正确和快速将是非常困难的。不要自己滚。相反，使用一个完善的、经过测试的系统进行可靠的任务排队。看看RabbitMQ、ZeroMQ、ApacheActiveMQ、Celery等。还有来自Skytools的PGQ，这是一个基于PostgreSQL的解决方案。

相关的：

• 在PostgreSQL中，对同一个表中的不同行进行多次更新时是否存在锁定冲突？