SELECT FOR UPDATE и очередь задач

Гонка lost update и пессимистичный фикс

Прежде чем тянуться к FOR UPDATE, спроси себя: читаю ли я значение и пишу ли затем решение, основанное на нём? Если да, и другая сессия может сделать то же самое конкурентно, — у тебя прямо сейчас окно для lost update.

Умолчание READ COMMITTED не сериализует read-then-write, сделанный двумя операторами. Две сессии могут обе прочитать баланс, обе вычислить новое значение по устаревшему чтению и обе записать — вторая молча перезатирает первую. Это lost update.

-- Сессия 1 и Сессия 2 обе выполняют это, чередуясь:
SELECT balance FROM accounts WHERE id = 1;   -- обе читают 500
-- приложение вычисляет 500 - 100 = 400
UPDATE accounts SET balance = 400 WHERE id = 1;  -- обе пишут 400; одно списание исчезает

SELECT ... FOR UPDATE чинит это пессимистично: он берёт блокировку записи уровня строки на каждую возвращённую строку. Вторая транзакция, пытающаяся заблокировать ту же строку, блокируется до коммита первой, затем продолжает по уже актуальным данным.

BEGIN;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;  -- блокирует строку
-- только эта транзакция держит её; другие ждут здесь
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;  -- блокировка снимается; следующий ожидающий перечитывает свежий баланс

Блокировка живёт остаток транзакции и снимается на COMMIT или ROLLBACK. Цена — сериализация: спорные строки обрабатываются по одной транзакции за раз. В этом и смысл — корректность важнее пропускной способности на горячей строке.

Четыре силы блокировок

В Postgres четыре режима блокировки строк, от сильнейшего к слабейшему. Выбор слабейшего корректного пропускает больше конкурентности.

• FOR UPDATE — полная блокировка записи. Блокирует любой другой FOR UPDATE/FOR SHARE и блокирует UPDATE/DELETE строки. Используй, когда будешь менять строку.
• FOR NO KEY UPDATE — чуть слабее; берётся автоматически обычным UPDATE, не трогающим ключевую колонку. Он не блокирует FOR KEY SHARE, который берут проверки foreign key — так что снижает FK-конкуренцию.
• FOR SHARE — разделяемая блокировка чтения. Несколько транзакций могут держать её; она блокирует писателей. Используй, чтобы закрепить читаемую, но не меняемую строку.
• FOR KEY SHARE — слабейшая; её берёт проверка существования по foreign key на родительской строке. Блокирует лишь изменения ключа строки.

Практический урок: INSERT в дочернюю таблицу берёт FOR KEY SHARE на родителя, а UPDATE неключевой колонки родителя берёт FOR NO KEY UPDATE — эти два сделали совместимыми, чтобы обычный FK-трафик не сериализовался. Тянись к простому FOR UPDATE только когда реально намерен обновить заблокированную строку.

SKIP LOCKED: каноничная конкурентная очередь

SKIP LOCKED меняет поведение ожидания: вместо блокировки на уже занятой строке запрос пропускает её и возвращает следующую доступную. Это ровно то, что нужно очереди задач — каждый воркер хватает другую незанятую задачу.

-- Атомарный dequeue одного воркера: взять старейшую свободную задачу, пропуская занятые соседом.
BEGIN;
SELECT id FROM jobs
WHERE status = 'queued'
ORDER BY id
FOR UPDATE SKIP LOCKED
LIMIT 1;
-- пометить взятую строку, чтобы её не выбрали снова после коммита:
UPDATE jobs SET status = 'running', locked_at = now() WHERE id = :claimed_id;
COMMIT;

Десять воркеров, выполняющих это параллельно, каждый блокирует и берёт отдельную строку; нет дублей, нет блокировок, почти линейное масштабирование. Так работают Sidekiq-Pro, pg-boss, Que и большинство современных Postgres-очередей — без отдельного брокера, просто FOR UPDATE SKIP LOCKED.