SKIP LOCKED распределяет задачи, но не возвращает их после падения воркера
SKIP LOCKED распределяет задачи, но не возвращает их после падения воркера Запрос: SELECT id FROM jobs WHERE status = 'pending' ORDER BY created_at, id FOR UPDATE SKIP LOCKED LIMIT 10; Несколько воркеров могут пропускать занятые строки и забирать другие доступные задачи. Но SKIP LOCKED не управляет жизненным циклом: pending → processing → done / failed / retry Если воркер поставил processing, сделал COMMIT и упал, PostgreSQL сам не вернёт задачу в pending. Нужны правила: — выбор и переход в processing атомарны; — транзакция не держится вокруг долгой внешней работы; — записываются worker_id и lease_until; — просроченные задачи возвращаются по осознанному правилу; — запись done проверяет владельца; — retry ограничены; — повторная обработка безопасна; — старые pending и processing наблюдаются отдельно. Важно: SKIP LOCKED даёт неполный результат. Старая заблокированная задача может пропускаться, пока обрабатываются более новые доступные строки. Типичная ошибка — добавить одну locking clause и считать очередь надёжной. Вывод: проектируйте полный жизненный цикл задачи и восстановление после сбоя, а не только конкурентный SELECT. Сохраните сценарий для проверки PostgreSQL-очередей, где несколько воркеров забирают задачи параллельно. #УЦФОРС #PostgreSQL #SQL #Backend #Очереди