В PostgreSQL 19 появились четыре системные вьюхи. Звучит как мелочь из changelog, но каждая закрывает конкретную дыру, вокруг которой годами городили костыли: парсинг логов, дёрганье несогласованных функций, догадки о поведении autovacuum.
По материалам статьи PostgreSQL 19: new system views (Gülçin Yıldırım Jelínek, 1 сентября 2026). Разбор мой.
Обновление от 17 сентября 2026. Релиз PostgreSQL 19 сдвинут: часть фич откатили прямо в бете. Описанные ниже вьюхи в список названных откатов не попали, но перед тем как на них закладываться, сверьтесь с финальными release notes.
pg_stat_lock — накопительная статистика блокировок
Раньше выбор был из двух неудобных вариантов: pg_locks даёт мгновенный снимок (поймать проблему можно только если повезло смотреть в нужный момент), либо включать log_lock_waits и парсить логи руками.
Новая вьюха даёт накопительные счётчики по всему кластеру в разрезе 12 типов блокировок: relation, transactionid, tuple, extend, page, object, advisory, virtualxid, spectoken, applytransaction, frozenid, userlock.
SELECT locktype, waits, wait_time FROM pg_stat_lock WHERE waits > 0;Что в колонках:
waits— сколько раз ждали блокировку;wait_time— суммарное время ожидания в миллисекундах;fastpath_exceeded— сколько раз упёрлись в лимит слотов fast-path.
Важное ограничение: считаются только ожидания дольше deadlock_timeout (по умолчанию 1 секунда). То есть это не полная картина всех блокировок, а «сколько раз было по-настоящему больно». Для мониторинга это скорее плюс — шум отсекается сам, — но не стройте на этих цифрах точный учёт contention.
Последняя колонка интереснее, чем кажется: рост fastpath_exceeded — сигнал, что запросы трогают слишком много объектов за транзакцию (много партиций, например), и блокировки начинают идти дорогим путём.
pg_stat_recovery — согласованное состояние реплики
Тут исправили давнюю концептуальную проблему. Состояние восстановления раньше собиралось из отдельных функций: pg_is_in_recovery(), pg_last_wal_replay_lsn() и компания. Каждая читается под своей блокировкой и в свой момент времени — то есть согласованного среза не получалось в принципе. Вы могли увидеть LSN от одного мгновения и timeline от другого.
pg_stat_recovery отдаёт атомарный снимок: позиции LSN, timeline, время последней транзакции, статус promote и паузы.
Ключевые поля:
last_replayed_end_lsn,last_replayed_tli— что именно доиграно и на каком timeline;recovery_last_xact_time— время коммита/отката транзакции на primary (из этого считается настоящий лаг по времени);promote_triggered— идёт ли повышение до primary. Раньше из SQL это было не видно вообще — приходилось смотреть в файлы и логи.
Ограничения простые: на primary вьюха возвращает ноль строк, а для чтения нужна роль pg_read_all_stats.
Для тех, кто строит автоматику failover, promote_triggered — самое ценное здесь: появился штатный способ отличить «реплика отстаёт» от «реплика прямо сейчас становится мастером».
pg_stat_autovacuum_scores — и смена модели autovacuum
Эта вьюха — верхушка более крупного изменения. В PostgreSQL 19 autovacuum перешёл с FIFO на приоритизацию по баллам. Раньше таблицы обрабатывались в порядке обнаружения; теперь каждой считается score, и первыми идут самые проблемные.
Вьюха показывает эти баллы по таблицам:
SELECT relname, score, do_vacuum, do_analyze FROM pg_stat_autovacuum_scores
WHERE do_vacuum OR do_analyze ORDER BY score DESC;score— итоговый приоритет, максимум из компонент;- компоненты:
xid_score(возраст XID),mxid_score(возраст multixact),vacuum_score(мёртвые кортежи),vacuum_insert_score(давность вставок),analyze_score(устаревание статистики); do_vacuum,do_analyze,for_wraparound— что именно планируется сделать.
Практическая ценность: теперь можно заранее увидеть, до какой таблицы autovacuum доберётся нескоро, вместо того чтобы узнавать об этом из растущего bloat или приближающегося wraparound. Разбивка по компонентам сразу говорит, что именно тянет приоритет вверх — возраст транзакций или мёртвые кортежи.
Оговорка: баллы считаются по текущей статистике, а воркеры autovacuum оценивают таблицы в разные моменты. Так что вьюха — это оценка, а не расписание.
pg_dsm_registry_allocations — сегменты динамической разделяемой памяти
Самая узкая из четырёх. Расширения, которые выделяют разделяемую память в рантайме через DSM registry, раньше были невидимы из SQL — понять, кто и сколько занял, было нечем.
Теперь видно имя, тип (segment / area / hash) и размер в байтах. Если размер NULL — инициализация не удалась, и это готовый признак сломанного расширения.
Нужна не всем: полезна, если вы живёте с набором расширений или пишете свои.
Что с этого практически
Три вещи, которые стоит сделать при переходе на 19:
- Завести алерт на
pg_stat_lock— ростwait_timeпо конкретномуlocktypeпоказывает характер проблемы точнее, чем общая метрика «медленно». - Переписать мониторинг реплик на
pg_stat_recovery— вместо набора функций один согласованный запрос, плюс наконец видноpromote_triggered. - Посмотреть
pg_stat_autovacuum_scoresна своей нагрузке — модель приоритизации изменилась, и поведение autovacuum после апгрейда будет другим. Лучше узнать это заранее, а не по факту.
Общий вектор понятный: PostgreSQL закрывает места, где раньше требовалось парсить логи или собирать состояние из несогласованных источников. Наблюдаемость становится частью базы, а не надстройкой над ней.