Базы данных
MVCC и изоляция: тест на припоминание
Припоминание сильнее перечитывания. Для каждого промпта проговори или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания заставляет механизм держаться в голове, когда он нужен в 3 часа ночи.
Реконструируй спину юнита, не подглядывая: правило видимости, что каждый isolation level предотвращает и допускает, разницу между write skew и lost update, что пинит oldest xmin и как SSI ловит write skew.
- 01Что такое снимок (snapshot) в Postgres (три числа) и какое правило видимости применяется к каждому tuple?
- 02READ COMMITTED против REPEATABLE READ: когда берётся снимок и какая аномалия их различает?
- 03Отличи lost update от write skew и назови фикс для каждого.
- 04Что такое глобальный oldest xmin и почему долгая транзакция или orphan replication slot вызывают неограниченный bloat через него?
- 05Какие два условия делают UPDATE HOT-обновлением и почему это важно для стоимости записи?
- 06Как SSI обнаруживает write skew, чем отменяет и какова ожидаемая доля ложных срабатываний?
Если ты реконструировал каждый ответ по памяти, ты держишь спину юнита: снимок плюс заголовок tuple — это весь механизм видимости; выбранный isolation level решает, какими аномалиями владеешь ты — RC оставляет lost update приложению, REPEATABLE READ стабилизирует чтения и ловит конкурентные обновления строки, но допускает write skew, SERIALIZABLE добавляет SSI для ловли циклов write skew через зависимости predicate locks; HOT-обновления режут стоимость записи, когда не меняется индексируемый столбец и на странице есть место; а глобальный oldest xmin — рычаг почти за каждым инцидентом bloat: долгая транзакция или orphan slot пинят его, и autovacuum тихо становится бесполезным.