В статье рассматривается создание кластера 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, которые позволяют выводить логирование соединений в отдельный файл аудита.

Если вы инженер в крупной компании, а особенно если ваша организация поставляет свои услуги в виде SaaS-решений, то вам так или иначе придется решать задачу мониторинга работы всех ваших баз PostgreSQL. На них часто бывает завязан функционал, важный для компании с точки зрения финансовых рисков, поэтому крайне желательно организовать не только мониторинг, но и получение уведомлений, когда что-то идет не по плану (или пойдет в ближайшем будущем). В рамках статьи мы рассмотрим несколько способов, как это можно сделать: самостоятельно, с использованием уже привычного стека Prometheus + Grafana, либо подключая сторонние open-source специализированные решения для мониторинга PostgreSQL, либо же используя специализированные платные решения. По каждому варианту поймем все плюсы и минусы, чтобы вы cмогли более уверенно выбрать свой путь.

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

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

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

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

Когда имеется несколько индексов с одинаковыми ведущими столбцами, иногда выбирается не лучший индекс, и время выполнения запроса увеличивается на порядки. Такие ситуации встречаются в сложных приложениях, но чаще всего в 1С:ERP, поскольку это приложение наиболее распространено. Как это обычно бывает: после миграции приложения на СУБД PostgreSQL часть запросов начинает выполняться медленнее. Планировщик выбирает индекс, созданный по меньшему числу столбцов, время выполнения увеличивается, потому что при использовании такого индекса индексные записи указывают на строки таблицы, которые не соответствуют условиям соединения. При выборе же индекса по большему числу задействованных в запросе столбцов время выполнения становится существенно ниже и практически не зависит от размера таблиц.

В статье детализируется часть доклада Максима Старкова на конференции PG BootCamp, которая прошла в апреле в Екатеринбурге. Описываются признаки таблиц и индексов, при работе с которыми может возникнуть проблема выбора худшего индекса, а также рассматривается пример, демонстрирующий, что строка "Buffers" характерна для определения эффективности выполнения запроса (в 18 версии PostgreSQL "Buffers" будет показываться в планах по умолчанию).

При создании временных таблиц в PostgreSQL изменяются до 13 таблиц системного каталога, при этом особенно сильно разрастаются pg_attribute, pg_class, pg_depend и pg_type. Массовое создание и усечение временных таблиц активно применяется, в том числе в 1C:ERP. В статье рассматриваются особенности работы с временными таблицами и описано решение проблемы раздувания таблиц системного каталога, реализованное в СУБД Tantor Postgres.

Большая часть времени планировщика запросов в СУБД тратится на поиск оптимального способа соединения таблиц. В PostgreSQL используется два алгоритма: алгоритм динамического программирования, также называемый DPsize, и генетический — GEQO. В других СУБД реализовано еще множество других алгоритмов. DPhyp — алгоритм соединения на основе гиперграфов — уже используется такими СУБД как MySQL и YDB. Я задался вопросом: можно ли реализовать его в PostgreSQL? Оказывается, можно. Так и зародилось расширение pg_dphyp для PostgreSQL, реализующее альтернативный алгоритм соединения таблиц. В статье я не описываю подробно сам алгоритм, привожу только концептуальное описание его идеи, а рассказываю вот о чем:

-- Какие решения пришлось принять, чтобы добавить алгоритм DPhyp в существующую кодовую базу без изменения ядра;
-- Как GPLv2 помог найти эффективный алгоритм обхода соседей;
-- Как проиндексировали неиндексируемое гиперрёбра;
-- Планирование какого запроса смогли ускорить в 600 раз;
-- Какой изъян в работе существующего планировщика был найден.

Но главный сюжетный поворот — в конце...

На апрельской конференции PG BootCamp 2025 в Екатеринбурге был представлен доклад Артёма Бугаенко о том, как сделать статистику Postgres более детализированной, не повышая DST. Однако если посмотреть на доклад под немного другим углом, то ему отлично подошло бы название «Пример создания патча для PostgreSQL». Примеры правки логики планировщика есть во многих патчах, но объяснение того, куда и какой код нужно вставлять в многочисленные файлы исходного кода PostgreSQL, встречается нечасто. Можно встретить примеры описания того, как добавить параметры конфигурации, а вот пример того, как добавить опцию в команду SQL, найти подчас затруднительно. Поэтому если вам требуется добавить в какую-либо команду свою опцию, можно использовать статью, доклад и предложенный докладчиком патч как руководство.

Новый релиз СУБД Tantor Postgres 17.5 насыщен обновлениями во всех основных аспектах: усиление безопасности, повышение общей производительности, новые расширения, а также инфраструктурные улучшения. Сегодня мы проведем обзор изменений, касающихся работы с высоконагруженными системами 1С. Релиз предлагает не просто несколько точечных исправлений, а целый арсенал специализированных функций, призванных существенно ускорить выполнение типичных для 1С операций, снизить нагрузку на инфраструктуру и упростить администрирование. Спектр улучшений распространился на многие ключевые узлы производительности от оптимизации работы с временными таблицами и сложными запросами RLS (row-level security) до ускорения критически важных процессов наподобие «Закрытия месяца». Обо всем этом и пойдет речь в статье.

Привет, Хабр! Мы продолжаем цикл статей о нововведениях СУБД Tantor Postgres 17.5.0, и сегодня поговорим о поддержке авторизации через OAuth 2.0 Device Authorization Flow — это современный и безопасный способ предоставления доступа, который позволяет приложениям запрашивать доступ к PostgreSQL от имени пользователя через внешнего провайдера идентификации и управления доступом, например Keycloak, что особенно удобно для облачных сред и микросервисных архитектур (функция будет также доступна в PostgreSQL 18). В статье пошагово разберём настройку OAuth-авторизации в PostgreSQL с использованием Keycloak: настроим Keycloak, подготовим PostgreSQL, напишем валидатор токенов OAuth в PostgreSQL и проверим успешную авторизацию через psql с использованием Device Flow.

pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.

Внутристраничная очистка (HOT cleanup) — это оптимизация, благодаря которой старые версии строк могут эффективно удаляться из блоков таблиц. Освобождённое место используется под размещение новой версии строки. Освобождается только место, занимаемое версиями строк, вышедшими за горизонт базы данных (xmin horizon). В статье рассматривается алгоритм работы аналогичной оптимизации для индексов. Если горизонт удерживается, то ни внутристраничная очистка, ни вакуум не могут освободить место, и тогда новая версия строки вставляется в другой блок. Увидим на примере стандартного теста pgbench, как сильно может снижаться производительность при удержании горизонта базы данных (в случае когда есть сессия с долгим запросом или транзакцией) и разберемся в причинах снижения производительности.

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

При нагрузочном тестировании баз данных Tantor Postgres или других на базе PostgreSQL с использованием стандартного инструмента pgbench отсутствие фиксации деталей окружения (таких как конфигурация СУБД, характеристики сервера, версии ПО) часто приводит к нерепрезентативным результатам и необходимости повторных тестов. В статье рассматривается разработанный автором инструмент pg_perfbench, который призван решить эту проблему.

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

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

Если в таблицах БД PostgreSQL есть поля большого размера, при выгрузке часть строк таких таблиц может не выгружаться с выдачей ошибки ERROR: out of memory. Столкнуться с подобной ситуацией можно, например, при выгрузке утилитой pg_dump таблиц, в которых хранятся XML-документы, или при выгрузке таблицы public.config системы «1C:Предприятие». В статье рассматриваются причины возникновения подобных ошибок и способы решения проблемы.