你的思路本身是对的——用SELECT ... FOR UPDATE SKIP LOCKED实现多worker并行取任务、崩溃自动释放锁的机制非常合理，唯一的问题是默认查询在无任务时直接返回空，没有阻塞等待的逻辑。我们可以通过PostgreSQL的LISTEN/NOTIFY机制来补上这个缺口，让worker在无任务时进入等待状态，直到新任务插入时被唤醒。

具体实现步骤 #

1. 添加任务插入通知触发器 #

首先给队列表创建一个触发器，每当有新任务插入时，向特定频道发送通知：

-- 创建通知函数
CREATE OR REPLACE FUNCTION notify_new_job()
RETURNS TRIGGER AS $$
BEGIN
  -- 发送通知到"new_job"频道，携带新任务ID（可选，实际用不到，仅作示例）
  PERFORM pg_notify('new_job', NEW.id::text);
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- 绑定触发器到队列表的插入操作
CREATE TRIGGER trigger_new_job
AFTER INSERT ON queue
FOR EACH ROW EXECUTE FUNCTION notify_new_job();

2. 修改Worker逻辑，加入等待机制 #

调整你的worker伪代码，当查询不到任务时，监听通知频道，直到收到新任务插入的通知后再重新查询：

# 伪代码（适配你的编程语言/数据库驱动）
while True:
    tx = db.new_transaction()
    try:
        # 尝试获取可用任务
        job_result = tx.query("SELECT id, some_job_param1, some_job_param2 FROM queue FOR UPDATE SKIP LOCKED LIMIT 1")
        
        if job_result:
            # 拿到任务，开始处理
            job_id, param1, param2 = job_result[0]
            some_long_processing(param1, param2)
            
            # 处理完成后删除任务并提交事务
            tx.execute("DELETE FROM queue WHERE id = %s", (job_id,))
            tx.commit()
        else:
            # 无任务，先提交空事务（LISTEN需要在非事务会话中才能及时接收通知）
            tx.commit()
            
            # 监听新任务通知频道
            db.listen('new_job')
            # 等待通知到来（具体方法取决于你的数据库驱动，比如psycopg2的conn.wait()）
            db.wait_for_notify()
            
            # 收到通知后取消监听，进入下一轮循环查询
            db.unlisten('new_job')
    except Exception as e:
        # 处理异常，回滚事务释放锁
        tx.rollback()

关键注意事项 #

• 为什么要提交空事务再监听：PostgreSQL的LISTEN是会话级操作，但如果在未提交的事务中监听，通知可能无法被及时接收（不同驱动表现有差异），所以先提交空事务，确保会话处于非事务状态再监听。
• 不要依赖通知内容：通知里的任务ID只是示例，实际收到通知后直接重新查询队列即可——因为可能同时插入多个任务，通知只触发一次，但队列里会有多个可用任务。
• 超时兜底：如果你的数据库驱动支持，可以给wait_for_notify设置一个超时时间（比如30秒），超时后自动重新查询队列，避免因通知丢失（虽然PostgreSQL的NOTIFY是可靠的）导致worker一直等待。
• 原有崩溃恢复逻辑不变：worker崩溃后事务自动回滚，被锁定的任务会立即释放，其他worker可以正常拾取，这个逻辑完全不受影响。

替代方案说明 #

如果你不想用LISTEN/NOTIFY，也可以用轮询+休眠的方式，但这会带来不必要的数据库查询开销，不如通知机制高效。另外，不要尝试去掉SKIP LOCKED——如果只用SELECT ... FOR UPDATE，多个worker会排队等待同一个被锁定的任务，完全失去并行处理的能力，不符合你的需求。

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