Блог

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

Если вы инженер в крупной компании, а особенно если ваша организация поставляет свои услуги в виде SaaS-решений, то вам так или иначе придется решать задачу мониторинга работы всех ваших баз PostgreSQL. На них часто бывает завязан функционал, важный для компании с точки зрения финансовых рисков, поэтому крайне желательно организовать не только мониторинг, но и получение уведомлений, когда что-то идет не по плану (или пойдет в ближайшем будущем).

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

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

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

Технически доклад довольно сложен, рассматривается в нём сразу несколько тем: алгоритм вычисления стоимости индексного доступа с точки зрения разработчика, проблема вычисления селективности при использовании предиката с несколькими условиями, проблема неиспользования расширенной статистики с параметризованным индексным доступом (parameterized scan), а также описывается патч, который позволяет её использовать. 

В статье рассматриваются особенности работы с временными таблицами и описано решение проблемы раздувания таблиц системного каталога, реализованное в СУБД Tantor Postgres. Начиная с версии 17.5, при создании и удалении временных таблиц, а также при работе с временными объектами таблицы системного каталога не изменяются.

Эта статья не о DPhyp как таковом, а о том, с чем мне пришлось столкнуться в процессе написания расширения pg_dphyp (репозиторий) для PostgreSQL, реализующего этот алгоритм. 

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