如何将PostgreSQL表用作带尝试次数统计的任务队列

针对你提出的任务处理器并发调度需求，这里提供一个基于PostgreSQL原子操作的解决方案，完全满足你设定的两个条件：

核心思路 #

利用PostgreSQL的UPDATE ... RETURNING结合FOR UPDATE SKIP LOCKED特性，将「锁定符合条件的任务」「递增处理尝试次数」「返回任务数据」三个操作合并为一个原子性事务，从根本上避免并发冲突和会话崩溃导致的状态不一致问题。

具体实现代码 #

假设你设定的最大尝试次数K为3，可执行以下SQL（自动提交模式下直接运行即可）：

WITH target_task AS (
    SELECT id
    FROM tasks
    WHERE processing_attempts < 3
    ORDER BY creation_time ASC
    LIMIT 1
    FOR UPDATE SKIP LOCKED
)
UPDATE tasks
SET processing_attempts = processing_attempts + 1
FROM target_task
WHERE tasks.id = target_task.id
RETURNING tasks.*;

代码说明 #

1. CTE子查询target_task：按创建时间从早到晚筛选出处理尝试次数小于K的任务，通过FOR UPDATE SKIP LOCKED锁定该行，同时让其他并发处理器跳过已锁定的任务，确保同一任务不会被多个处理器选中。
2. UPDATE语句：对锁定的任务递增processing_attempts，整个操作是原子性的——要么完全执行成功，要么完全回滚。
3. RETURNING子句：更新完成后返回该任务的所有数据，处理器只有拿到返回结果，才意味着成功获取到任务。

方案如何满足你的条件 #

• 单个任务仅能被一个处理器获取：FOR UPDATE SKIP LOCKED机制保证了同一时间只有一个处理器能锁定并选中目标任务，其他处理器的查询会自动跳过已锁定的行，不会出现重复获取的情况。
• 任务被获取后会话崩溃，尝试次数已递增：只有当UPDATE操作成功完成并返回任务数据时，处理器才算“获取”到任务。此时processing_attempts已经完成更新（自动提交模式下已永久生效），哪怕后续会话意外终止，任务的尝试次数也不会回滚，完全符合要求。

额外注意事项 #

• 如果需要调整最大尝试次数K，只需修改WHERE processing_attempts < 3中的数字即可。
• 若当前没有符合条件的任务，SQL会返回空结果，处理器可进入等待状态后重试。

内容的提问来源于stack exchange，提问作者lvella