Дубль появился не потому, что SELECT ошибся — 15 июля 2026 г. в 10:33:01.499
Дубль появился не потому, что SELECT ошибся Сценарий: T1: SELECT — строки нет T2: SELECT — строки нет T1: INSERT T2: INSERT Два параллельных запроса проверили, что заказа ещё нет, и оба создали строку. Так бывает, когда уникальность держится только на уровне приложения: сначала проверим потом вставим Но между проверкой и вставкой есть окно гонки. В это окно может попасть другая транзакция. Что помогает закрыть проблему: — UNIQUE-ограничение или уникальный индекс по бизнес-ключу; — корректная обработка конфликта вставки; — INSERT ... ON CONFLICT, если сценарий подходит; — идемпотентный ключ для повторных запросов; — понятная граница транзакции; — блокировки там, где действительно нужно защищать общий ресурс. Важно: повторная проверка в приложении не заменяет ограничение в БД. При конкурентном выполнении она может попасть в то же окно гонки. Вывод: если дубли недопустимы по модели данных, база должна знать это правило. А приложение должно быть готово не только проверить перед вставкой, но и корректно обработать конфликт. Сохраните сценарий: он полезен при разборе дублей, повторных запросов и гонок в бизнес-логике. #УЦФОРС #PostgreSQL #SQL #Backend #Транзакции