В статье рассматриваются особенности использования ограничений целостности с проверкой, которую можно отложить до фиксации транзакции, а также использование системных триггеров для проверки ограничений целостности. Триггеры создаются для любых внешних ключей - и с немедленной и отложенной проверкой, а для уникальных ключей - только для ограничений с отложенной проверкой. Для уникальных откладываемых ключей создаются уникальные индексы, которые допускают неуникальные значения. В таблице могут находиться строки, нарушающие ограничение уникальности, при том, что статус ограничения целостности в системном каталоге "проверено" (validated).

Планы выполнения запроса формируются на основе текста самого запроса, статистик и параметров конфигурации. Для сбора статистики нужны данные в таблицах. В PostgreSQL 18 версии появились функции pg_restore_relation_stats и pg_restore_attribute_stats, которые могут записать статистики в системный каталог. Вместе с возможностью выгрузки статистики параметром утилиты pg_dump --statistics-only, статистику стало возможым переносить между базами данных.

Функционал переноса статистики был создан для обновления кластера баз данных на новые версии. До 18 версии статистика не выгружалась, собиралась после обновления. Сбор статистики по большому числу таблиц довольно долгий. Начиная с 18 версии, утилита pg_upgrade, по умолчанию, сохраняет статистику.

Этот же функционал можно использовать для переноса статистики с промышленных на тестовые базы данных. В статье рассматривается как это сделать.

В PostgreSQL процесс получения журналов walreceiver запускается на реплике только после того, как процесс startup применит все накопившиеся WAL. Это не создаёт особых проблем, если процесс startup успевает накатывать полученные журналы. Проблема проявляется, если используется реплика с отложенным применением журнальных записей, например, на сутки. Реплика не будет получать журналы сутки, слот репликации будет их удерживать на мастере.

Если процесс walreceiver остановится, то он не запустится до тех пор, пока не пройдёт время задержки, установленное параметром recovery_min_apply_delay. Команд ручного запуска процесса walreceiver нет. Получится, что сутки мастер копит журналы, только потом запускается walreceiver и начинает вытягивать журнальные файлы. Такое поведение нелогично, но его задокументировали: "When the standby is started and primary_conninfo is set correctly, the standby will connect to the primary after replaying all WAL files available in the archive. If the connection is established successfully, you will see a walreceiver in the standby, and a corresponding walsender process in the primary."

Всё время, до запуска walreceiver, слот репликации на мастере удерживает файлы журналов. На мастере скопится много журналов и, если не хватит места, то экземпляр мастера подвиснет по нехватке места в директории pg_wal (или слот инвалидируется по параметру max_slot_wal_keep_size и реплику придётся пересоздать).

В обсуждении под статьями «СУБД Tantor Postgres 18: обзор улучшений для 1С» и «В погоне за APDEX‑ом, или как создать HighLoad на недорогом серверном железе» чрезвычайно уважаемые люди задались вопросом про *_collapse_limit и его отношение к geqo_threshold. В сообществе обсуждали эти параметры в большом топике, в этой статье коротко описано то, к чему там пришли.

Число 20 взялось из поста Роберта Хааса 2009 года по то, можно ли что‑то сделать с параметрами *_collapse_limit в PostgreSQL версии 8.5, которая в то время выходила.

Утилита резервирования pgBackRest перестала поддерживаться, стало актуальным найти ей замену. Главными альтернативами называют WAL-G и Barman. Можно использовать pg_basebackup+pg_receivewal. Преимущество WAL-G в том, что резервирование возможно по протоколу S3, WAL-G обеспечивает более высокую скорость резервирования и сжатия, имеет неплохие перспективы развития. Кроме протокола S3, WAL-G может резервировать и восстанавливать из директории в файловой системе, работает с Patroni. Директория с бэкапами не обязательно должна находиться на локальном диске, можно смонтировать любую файловую систему, например, NFS. Утилита свободно распространяемая.

В статье рассматриваются примеры команд, которыми можно резервировать и восстанавливать PostgreSQL утилитой WAL-G с обеспечением защиты от потерь транзакций (zero data loss).

Потоковая репликация - это хорошо зарекомендовавшая себя техника физической репликации в режиме мастер-реплики. Она проста в настройке, стабильна и демонстрирует высокую производительность. Многие удивляются, когда узнают о конфликтах при репликации - ведь реплики работает только в режиме чтения.

В статье описываются конфликты репликации и как с ними бороться.

Ожидания получения BufferPin включают в себя:

1) Конфликты BufferPin на репликах (recovery conflict). Процесс на реплике startup должен получить блокировку на буфер, чтобы проиграть (replay, apply, накатить журнальную запись) HOT cleanup блока, для этого startup должен дождаться pincount=0. Быстрая очистка (HOT cleanup) выполняется на мастере серверными процессами очень часто и процесс startup, если столкнется с блоком, закреплённым запросом на реплике, полностью приостановит накат и будет ждать снятия закреплений блока. Накатом занимается только один процесс startup и в один поток. Из-за частых ожиданий BufferPin отставание реплики растёт и кажется, что startup не справляется. Мониторинг таких ситуаций затруднён, так как в представлении pg_stat_database_conflicts отражаются только конфликты, которые привели к прерыванию запросов на реплике, то есть, когда startup приостанавливал работу более, чем на max_standby_streaming_delay (по умолчению, 30 секунд), а в pg_stat_activity поймать ожидание BufferPin, которое длится доли секунды, почти невозможно. Из-за таких конфликтов, компаниии выделяют одну реплику, которая не обслуживает запросы, чтобы она только синхронизировалась и не отставала от мастера. Например, OpenAI, помимо 50 реплик, обслуживающих запросы на чтение, использует реплику, не обслуживающую никакие запросы, чтобы можно было на неё быстро переключиться (упомянута в 6 пункте в статье)

2) конфликты с автовакуумом при заморозке страниц. Такие конфликты есть и на мастере и на реплике и начинаются через 100 миллионов транзакций (по умолчанию, до 18 версии PostgreSQL). При недолгих тестированиях приложений не отлавливаются, проблемы начинаются при эксплуатации. Это одна из причин, по которой нагрузочные тесты длятся долго. Зная, как работает PostgreSQL, можно использовать недолгие тесты и оптимизировать приложение и параметры экземпляра, используя результаты недолгих тестов для обратной связи при настройке.

В статье - обзор доклада Алексея Копытова (автора sysbench) на конференции PG BootCamp 2026.

Доклад заинтересовал меня тем, что я только после конференции узнал, что Алексей - создатель утилиты sysbench, работал в MySQL AB (High Performance group within the MySQL Support Team) и Percona. MySQL используется в больших компаниях там, где нужна большая производительность. Это значит, что в мире MySQL есть разработчики, которые хорошо понимают архитектуру реляционных баз данных, то есть могут быстро внести в PostgreSQL программные решения из MySQL, которые повысят производительность и отказоустойчивость PostgreSQL.

Доклад Алексея Копытова шёл за докладом Вадима Яценко, чей доклад представил слушателям новую СУБД Tantor Polar. На момент доклада, за две недели до конференции, была опубликована статья, где подробно описывалась новая архитектура, поэтому выступление Яценко вызвало особый интерес и явилось публичной презентацией этих наработок.

В статье дан обзор одного из докладов конференции PgConf, которая прошла 23-24 марта 2026 года, Андрея Билле, главного инженера компании Pоstgres Prоfessiоnal. Название доклада: «Если ваш админ самурай или история о восстановлении очень нужных данных».

Прошла 5 ежегодная конференция PG BootСamp Russia 2026. В этот раз она проводилась в Москве 19 марта 2026 года. 563 оффлайн участника и порядка 1300 онлайн. Первая конференция прошла в 2023 году и дальше проводилась в разных городах. В статье - репортаж с конференции и краткий обзор докладов

В статье Дмитрия Ремизова дан качественный тест, проявляющий проблему конкуренции за блокировки типа LockManager. В статьях Дмитрия описываются интересные проблемы, возникающе при реальной эксплуатации. Было упомянуто, что проблема решена в 18 версии PostgreSQL без описания того, как решена. Эта статья закрывает пробел. Начиная с 18 версии, проблема ожиданий получения блокировки LWLock:LockManager при планировании запросов, в которых может использоваться суммарно более 16 таблиц (в том числе секций и TOAST) и индексов устранена.

Также даётся ответ на вопрос: если fastpath блокировки  хранятся отдельно для каждого процесса, как другие процессы проверяют наличие блокировок? В статье описано, почему блокировки по быстрому пути (fastpath) так эффективны и почему новшества в PostgreSQL, появившиеся в 18 так важны на практике.

В PostgreSQL устранили проблему невозможности выполнить контрольную точку на большом кэше буферов. В статье описываются условия возникновения проблемы, даётся пример диагностики статистики ввода-вывода в ситуациях, когда процесс checkpointer не успевает очищать свой круговой буфер. Также приводится алгоритм синхронизации файлов данных.

В PostgreSQL и Oracle Database команда UPDATE, столкнувшаяся с заблокированной строкой, ведёт себя по-разному. В статье рассматривается, как выполняется UPDATE в этих базах данных. Это может быть полезно при миграции кода приложения мжду этими базами данных.

В статье рассматривается создание кластера Patroni последней версии 4.0.7 и etcd 3.6.5 в контейнерах docker. Приводится пример, когда Patroni не может автоматически восстановить и запустить кластер PostgreSQL. 

Patroni в докере

Задача запуска Patroni в докере обсуждалась на реддит и гитхаб. Приводился пример наиболее простой сборки batonogov/patroni-docker, которая состоит из 7 контейнеров: трёх с кластером etcd и трёх с PostgreSQL 17 под управлением Patroni (мастер и две реплики), один контейнер с HAProxy.

Временные, или промежуточные данные — это данные, которые необходимы для обработки в рамках одной транзакции, сессии или в течение ограниченного периода, и удаляются после его завершения. Использование временных данных применяется в случаях, когда обработка всей информации за один запрос невозможна или нецелесообразна. Поэтому приложение может выполнять обработку по частям, используя несколько запросов. 

В статье будут рассмотрены основные методы хранения временных данных в PostgreSQL: обычные таблицы, нежурналируемые таблицы, материализованные преставления, временные таблицы и память серверного процесса с использованием расширения pg_variables.

В статье рассматривается логирование соединений с базами данных кластера PostgreSQL. Системы мониторинга создают сессии для сбора метрик и проверки доступности экземпляра. Это создаёт большое число записей в диагностическом журнале кластера, затрудняя его анализ. Администраторы ищут возможность отключения логирования для сессий мониторинга. Такая возможность есть только у параметра log_disconnections. Приводится пример, как с его помощью отключить логирование при создании сессии. Также рассматриваются особенности использования расширений pgaudit и pgaudittofile, которые позволяют выводить логирование соединений в отдельный файл аудита.

В планах выполнения запросов PostgreSQL рассчитывается два числа, которые показывает команда EXPLAIN:cost=A..B Без использования курсора, планировщик выбирает план с наименьшим значением B, а при использовании курсора: A + cursor_tuple_fraction * (B − A), где cursor_tuple_fraction - параметр конфигурации, который можно установить на уровне сессии и других уровнях.

Механизм реализации транзакций - основная часть реляционных баз данных. Он упрощает разработку приложений, в которых гарантируется целостность данных. Стандарт SQL регламентирует, часть свойств по поддержке транзакций, но многие детали не стандартизованы. Как следствие, реализация поддержки транзакций в разных базах данных может существенно различаться. В настоящее время, многие пытаются перейти с Oracle на PostgreSQL. Для миграции приложений важно понимать различия в реализации работы транзакций, иначе можно столкнуться с неприятными сюрпризами, которые могут поставить под угрозу производительность и целостность данных. Поэтому Лоренс Альбе решил, что полезно сравнить реализацию работы транзакций в Oracle и PostgreSQL и свести различия в одной статье.

Разбирая взаимоблокировки, Лоренс вспомнил, насколько опасным может быть использование SELECT FOR UPDATE при конкурентном доступе. В этом нет ничего нового, но Лоренс заметил, что многие не знают о режимах блокировки строк в PostgreSQL. Лоренс решил подробно описать, когда следует избегать SELECT FOR UPDATE.

Поводом для насписания статьи послужил доклад Евгения Воропаева «Разработка и отладка 64-битного счётчика транзакций» на конференции PG BootCamp 2025. При написании статьи была найдена реальная история патча и раскрыта тайна зоны special блоков PostgreSQL.

В статье описывается история создания патча, вводящего поддержку 64-битных номеров транзакций в PostgreSQL и почему он есть только в коммерческих форках. Статья особенно ценна тем, что под ней есть комментарий автора патча, Александра Короткова.