Базы данных
Миграции схемы: свободное припоминание
Припоминание сильнее перечитывания. На каждый промпт проговори или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет механизм, когда ты смотришь на замёрзшую таблицу в 2 часа ночи.
Восстанови ключевые механизмы юнита — FIFO-очередь блокировок, трюк missing-value из PG 11, NOT VALID/VALIDATE, expand-contract, WAL-флуд бэкфилла и сериализацию раннеров — не подглядывая в уроки.
- 01Почему мгновенный ALTER TABLE может заморозить нагруженную таблицу на 60+ секунд, и что именно за чем встаёт в очередь?
- 02Как PG 11+ делает ADD COLUMN с константным дефолтом мгновенным, и в чём разница для volatile-дефолта?
- 03Объясни паттерн NOT VALID + VALIDATE CONSTRAINT и почему он production-безопасен там, где обычный ADD CONSTRAINT — нет.
- 04Сформулируй ключевой инвариант expand-contract и пройди шесть фаз переименования колонки (username в handle).
- 05Почему одношаговый backfill затапливает WAL, что ломается ниже по потоку и какой ориентир по размеру батча?
- 06Почему down-миграции разрушают данные в продакшне, почему CREATE INDEX CONCURRENTLY нужны advisory lock и non-transactional аннотация рядом, и какова верная стратегия отката?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: FIFO-очередь блокировок означает, что ждущий ACCESS EXCLUSIVE замораживает таблицу за одним медленным запросом, поэтому lock_timeout обязателен; константный дефолт — это трюк каталога (attmissingval), тогда как volatile-дефолты всё ещё перезаписывают; NOT VALID + VALIDATE и CREATE INDEX CONCURRENTLY переносят тяжёлый скан на SHARE UPDATE EXCLUSIVE, так что DML продолжает работать; expand-contract держит совместимый с обеими версиями суперсет схемы через rename; батчевые бэкфиллы ограничивают WAL-флуд и replica lag; advisory lock’и сериализуют раннеры, а forward-миграции — никогда не down-миграции — это production-откат.