Почему ALTER TABLE ADD CONSTRAINT на большой таблице — отдельное эксплуатационное событие
Почему ALTER TABLE ADD CONSTRAINT на большой таблице — отдельное эксплуатационное событие Условный внешний ключ: ALTER TABLE orders ADD CONSTRAINT orders_customer_fk FOREIGN KEY (customer_id) REFERENCES customers (id); Операция должна получить блокировки на обе таблицы и проверить существующие данные. В PostgreSQL 18 обычный ADD FOREIGN KEY берёт SHARE ROW EXCLUSIVE, который конфликтует с операциями записи. Для внешнего ключа задачу можно разделить: 1. Добавить constraint как NOT VALID. 2. Сразу контролировать новые INSERT и UPDATE. 3. Отдельно проверить старые строки через VALIDATE CONSTRAINT. Но это не означает «без блокировок». Валидация использует более слабый lock mode, поэтому обычный DML может продолжаться, однако операция сканирует данные, создаёт нагрузку и может ждать конфликтующие DDL и maintenance-команды. До запуска проверьте: — целевую версию PostgreSQL; — тип ограничения; — размер и разделы таблицы; — существующие нарушения; — lock mode каждой фазы; — длинные транзакции; — порядок релиза приложения; — поведение при timeout и отмене; — критерий успешной валидации. Вывод: NOT VALID помогает разделить миграцию на этапы, но не превращает её в фоновую и безопасную операцию. #УЦФОРС #PostgreSQL #МиграцииБД #DevOps #Backend