В статье рассматривается создание кластера 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 и почему он есть только в коммерческих форках. Статья особенно ценна тем, что под ней есть комментарий автора патча, Александра Короткова.

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

В статье рассматриваются особенности типов данных для хранения вещественных чисел в PostgreSQL.

Типы данных PostgreSQL для работы с вещественными числами:

1) float4, синоним real, синоним float(1..24)

2) float8, синоним float, синоним double precision, синоним float(25..53)

3) numeric синоним decimal. Диапазон для этого типа значительный: 131072 цифр до точки и 16383 цифр после точки. Но если при определении типа указать numeric(точность, масштаб), то максимальные значения точности и масштаба 1000. numeric можно объявить с отрицательным масштабом: значения могут округляться десятков, сотен, тысяч.

Кроме чисел и null поддерживаются значения Infinity, -Infinity, NaN.

Поля типов данных фиксированной длины не могут вытесняться в TOSAT-таблицу, переменной длины (numeric) могут.

float4 обеспечивает точность 6 разрядов (значащих чисел в десятичной системе счисления), float8 обеспечивает точность 15 разрядов. Последний разряд округляется:

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

Доклады конференции PgBootcamp недавно выложили в общий доступ и их можно скачать и посмотреть.

 Введение

Доклады конференций полезны тем, что содержат описание того, что актуально при работе с PostgreSQL. Организаторы выбирают наиболее интересные доклады и не пропускают то, что уже всем известно.

О конференции PgConf я знал давно, а о конференции PgBootcamp я узнал год назад. За это время прошли три конференции: в Казани, Минске и Екатеринбурге. Архив докладов есть на сайте pgbootcamp.ru (регистрироваться на сайте не нужно, в "Программе" - список докладов, внизу каждого доклада ссылка на видеозапись доклада).

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

Значения восьми параметров конфигурации мастера (primary, ведущего сервера PostgreSQL) сохраняются в управляющих файлах и изменения их значений передаются через журнал (WAL) на реплики. Если реплика открыта для запросов (hot_standby=on), то значения пяти числовых параметров на реплике должны быть не меньше, чем на мастере, иначе процесс startup прекратит накат (replay) журнальных записей. А после рестарта экземпляры реплик не запустятся. В статье рассматриваются эти параметры особенности изменения их значений.

Значения пяти числовых параметров конфигурации, сохраненных в управляющем файле кластера, можно посмотреть утилитой pg_controldata:

В статье рассматривается использование теста TPC-H с PostgreSQL и проблемы, связанные с запросами Q17-Q20 теста.

Введение

Вместе с PostgreSQL поставляется утилит pg_bench с "TPC-B like" тестом. Кроме этого теста были созданы тесты TPC-R для отчётов, TPC-D для OLAP, TPC-W для заказов в веб-магазине, которые не получили распространения. На основе TPC-D был создан более удачный тест TPC-H для хранилищ данных и аналитических запросов ("OLAP нагрузка"). В тесте используется 8 таблиц и 17 ограничений целостности. В TPC-H выделены номинации по размерам обрабатываемых данных от "до 100Гб" до  30-100Тб. Тест TPC-H предназначен для хранилищ данных, включает в себя 22 запроса, которые называют Q1 ... Q22.

Запросы теста TPC-H не меняют данные в таблицах, а значит, для повторных тестирований не нужно пересоздавать или вакуумировать таблицы. В тестах TPC-B, TPC-C, TPC-E запросы довольно простые. В реальных приложениях запросы более сложные, чем в этих тестах. Поэтому для тестирования того, как СУБД выполняет запросы, которые могут встретиться в реальных приложениях, можно использовать все или отдельные запросы из теста TPC-H. Для быстрого аудита производительности различных СУБД используют вариант с 1Гб данных. В этом варианте запросы выполняются быстро, не нужно много памяти под экземпляр СУБД и много места на диске. Можно найти программы или скрипты для большинства СУБД, например, для PostgreSQL, Oracle Database, MySQL. После теста TPC-H появился тест TPC-DS с 99 запросами, но он менее популярен.

В статье визуализируется структура индекса и показывается, как меняется структура индекса типа btree в PostgreSQL. Это полезно для понимания, как выглядят индексы btree. Также рассматривается FILLFACTOR и пример исследования структуры индекса в целях определения, как перераспределяются индексные записи при включении в структуру индекса новых блоков (страниц). Создадим простую таблицу, индекс, вставим три строки:

На PgConf 2025 было три зала, в которых параллельно шли доклады. Поэтому охватить своим присутствием все доклады не представлялось возможным. В часть залов было не попасть, так как толпа участников толпилась на входе. Такое произошло и с докладом Михаила Жилина "Как PostgreSQL может сделать больно, когда не ожидаешь". В докладе описывалось 6 актуальных проблем. Проблема "#1: Глобальные счетчики" затрагивает почти все приложения, обновляющие строки в таблицах баз данных PostgreSQL. В этой статье рассматривают детали проблемы.

Закончилось основное событие года в мире PostgreSQL - PgConf 2025. В статье рассматривается патч, который ускоряет закрытие месяца в 1С-ERP в 10 раз, что довольно значительно. Патч был анонсировано в докладе "Быстрое закрытие месяца в 1С:ERP на PostgreSQL" или "Закрывай месяц в 1С ERP на PostgreSQL быстро и незаметно".

С 1С:ERP я не знаком, но знаю, что для 1С выпускаются специальные сборки PostgreSQL. Наполнившись решимостью узнать, что в этом 1С происходит я пожертвовал докладом про карту видимости, который шёл параллельно и не пожалел.

Я узнал, что в 1С никто ничего не делает, кроме как месяца закрывают и больше никого ничего не интересует, а также то, что по статистике пользователи приложения 1С:ERP делают что-либо, в среднем, раз в 20 минут. "Закрытие месяца" - набор расчетов и действий, которые могут выполняться часами. При этом с первого раза месяц обычно не закрывается, так как обнаруживаются ошибки учёта, которые должны быть исправлены и закрытие месяца повторяется заново. И так несколько раз. В докладе осветили нюансы установки границы итогов, удобство использования клонов кластера баз данных, описали причины проблем.

Основная интрига доклада была в том, что "секретный патч Фёдора Сигаева" ускоряет закрытие месяца в 10 раз (на порядок!). Не каждый день встретишь ускорение на порядок.

Порядок столбцов в таблицах влияет на компактность и производительность. При небольшом числе строк на это не обращают внимание. Если в таблицах хранится много строк, то даже небольшое уменьшение объема хранения может быть полезно. У столбцов есть оптимальный  порядок и менее оптимальные, которые отличаются размером, который используют строки при физическом хранении. Причина того, что переставив столбцы строки в таблице с теми же самыми данными, меняют размер в выравнивании (aligning) и заполнении нулями (padding). В блоке данных выравниваются все структуры: заголовки, поля строк и целиком сами строки.

На 64-разраядных операционных системах, длина любой строки и заголовка строки  выравниваются по 8 байт. То есть если строка занимает 28 байт, то физически она займёт 32 байта. В конец строки будут добавлены пустые байты. Поля выравниваются сложнее - по 4,8, 16 байт. В статье рассматривается перестановка столбцов на примере демонстрационной базы.

В распределённых базах данных YDB, CockroachDB по умолчанию используется уровень изоляции SERIALIZABLE. В PostgreSQL, Oracle Database, MySQL по умолчанию используется READ COMMITED. В стандарте SQL указаны только три аномалии. В статье приводится пример аномалии потерянного обновления в задаче "списания средств" и рассматривается, почему уровень READ COMMITED и ограничения целостности достаточны для решения задачи.

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

В представлении pg_locks есть столбец fastpath, который означает, что блокировка получена по быстрому пути. В документации быстрый путь блокирования описан коротко. В статье рассматривается быстрый путь блокирования и чем он лучше обычного пути.

РostgreSQL автоматически обнаруживает взаимоблокировки. В статье рассматривается процедура обнаружения взаимоблокировок, трудоёмкость процедуры обнаружения, причины, по которым параметр конфигурации log_lock_waits зависит от параметра deadlock_timeout и что влияет на выбор его значения. Приводится пример, как использование select for update может приводить к взаимоблокировкам и как взаимоблокировки влияют на метрики pgbench.

Подпрограммы (функции и процедуры) со свойством SECURITY DEFINER выполняются с правами владельца. Это даёт возможность непривилегированному пользователю выполнить маскировку объектов, к которым относятся не только таблицы, но и подпрограммы и выполнить команду с правами владельца подпрограммы. Если владелец является суперпользователем, то можно выполнить любую команду с правами суперпользователя. В статье рассматривается, как выполнить маскировку функции и как создавать безопасные подпрограммы.