Если ваш админ — самурай или «обнять и плакать»

На конференции PgConf компании Postgres Professional, которая прошла в Москве 23-24 марта 2026 года, было много интересных докладов.

В статье дан обзор, одного из докладов конференции, – Андрея Билле, главного инженера компании Postgres Professional.Название доклада: “Если ваш админ самурай или история о восстановлении очень нужных данных”. Доклад рекомендовали организаторы конференции, поэтому я решил его посетить и не пожалел. Этот доклад оказался наиболее зажигательным.

В докладе рассматривалось восстановление базы данных, у которой не было бэкапа. Использовалась бесплатная сборка от PostgresProfessional, в которой хранились данные приложений 1С.

Баз в кластере было 10 активно используемых баз данных, размер дорос до 2,5 террабайт. Работает это всё на виртуальной машине. Виртуальный диск создан без предварительного резервирования места имеет размер больше, чем физический диск. 3 года кластер работал без бэкапов и не ломался.

Файловая система хоста (гипервизора) неизвестна, Андрей Билле упоянул, что диск раздувался по “copy on write”.

Администраторы решают загрузить в кластер ещё одну инфобазу утилитой 1С. Настроено по методичке Антона Дорошкевича, много shared_buffers, исходя из чего Андрей Билле сделал вывод, что “всё нормально”. Но при загрузке места на диске  не остаётся, так как старые WAL не удаляются. Реплик нет, вероятная причина – не может выполниться контрольная точка.

Операционная система хоста (гипервизор), в которой работает виртуальная машина, посылает уведомление о заканчивающемся месте. Администраторы подсоединяются и удаляют WAL, так как они занимают много места (!) и пытаются штатно (в режиме fast) остановить экземпляр кластера. Андрей Билле сказал: в такой ситуации самое лучшее, что могли бы сделать это выдернуть шнур питания из розетки.

Экземпляр не останавливается, так как финальная (контрольная точка, которая выполняется при остановке экземпляра в режиме fast) контрольная точка не может завершиться.

Начат простой и администраторы аварийно (без контрольной точки) останавливают кластер. Что самое худшее, останавливают сигналом -9 (SIGKILL) а не SIGQUIT, причем сигналом процессу postmaster.

Сигнал 9 никогда нельзя посылать процессам PostgreSQL, а особенно postmaster. Из-за большого shared_buffers, скорее всего, натолкнулись на баг, описанный в статье ^[1]  когда контрольная точка не может завершиться, как следствие, WAL не могут удалиться.

В такой ситуации СУБД разрушается. Утилитой pg_resetwal отключают восстановление при запуске экземпляра.

На прошлой конференции тоже был доклад сотрудника техподдержки Postgres Prosessional про отключение восстановления утилитой pg_resetwal, только причина была в том, что экземпляр долго не стартовал. Так как докладов на эту тему много, то ИИ “обучился” рекомендует использовать pg_resetwal, утилита становится популярным способом повреждения кластеров баз данных PostgreSQL.

Андрей сказал, что так, как shared_buffers были очень большого размера, повреждений было тоже много.

Не стоит доверять методичкам из интернет, подумал я.

После запуска (без восстановления по журналам WAL) экземпляра, приложение 1C не смогло подключиться к СУБД, что неудивительно. Выяснили, что после создания сессии, запросы сложнее select 1 не выполняются. Администраторы стали стучаться во все двери и обратились к Антону Дорошкевичу, рекомендациями которого пользовались. Антон взялся помочь. Антон давно и тесно работает с Postgres Professional и Андрею Билле начальство сказало: “ты в одной временной зоне с Дорошкевичем и все его проблемы будешь решать ты”. Это нормально, так как не не только у Антона бывают проблемы с PostgreSQL, но и у Postgres Professional бывают проблемы с 1C и их взаимодействие взаимовыгодное.

Андрею консоль к серверу не дали, но так как использовали бесплатную сборку от Postgres Professional, то в сборке была утилита crash_info, которой Андрей и воспользовался. Эта утилита по 40 сигналу (SIGRTMIN+6) заставляет сбросить дамп состояния процесса операционной системы в файл на диске. Почему выбран такой номер сигнала Андрей не сказал, наверное, просто круглое число.

Серверный процесс, в котором подвисала любая команда, выполняла вызов btmoveright. По сокращению “bt” Андрей понял, что вызов относится к btree index. Догадался, что идёт обращение к индексу на таблицу системного каталога.

Андрею только позже подсказали, что патч можно было бы не делать, так как есть параметр конфигурации ignore_system_indexes. Андрей сказал, что он не инженер техподдержки, все параметры конфигурации (GUC) PostgreSQL он не знает, под боком у Билле есть ссылка на программиста, он дал задание программисту “а ты можешь сделать так, чтобы не использовались системные индексы”. Разработчик не стал перечить с сделал патч. Скомпилировали пропатченную сборку, отдали Дорошкевичу, он отдал клиентам, клиенты установили. Клиенту посоветовали запустить команду перестроения индексов на таблицы системного каталога PostgreSQL, то есть команду REINDEX SYSTEM.

Дело было вечером, с утра обнаружили, что команда не завершилась.

Параметрignore_system_indexes описан в учебном курсе Tantor DBA1-17 на видном месте:

но кто читает книги. Андрея Билле извиняет то, что в курсах Postgres Professional параметр не упоминался.

Полезных параметров конфигурации много. Видя, что администраторы не делают бэкапов, стирают WAL, отделы обучения ^[2] Tantor и Postgres Professional решили помочь компаниям оценивать квалификацию сотрудников. Tantorподготовил программу сертификации для DBA. Отдел обучения PostgresProfessionalобновил сертификационные тесты с 13 на 16 версию. В ближайшее время будет выпущен тест от Tantor по 17/18 версии и обновлённые тесты от Postgres Professional по 16 версии. Все тесты по ванильной версии PostgreSQL. Подготовка к тестам систематизирует знания и для подготовки можно будет прочесть учебники. И Тантор и Постгрес Профессиональный, выкладывают учебники к курсам в свободный доступ.

Дальше администраторы запустили утилиту pd_dump, но она подвисала на запросе, которым pg_dump в начале работы получает список таблиц, которые нужно выгрузить. Так как системные индексы были отключены, запрос, который выполняет pg_dump, без индексного доступа выполнялся за неприемлемо большое время, то есть “подвисал”.

Андрей Билле сказал, что Антон Дорошкевич сказал в своём докладе, что все данные о таблицах СУБД, 1С хранит в своих таблицах СУБД, а значит список индексов и таблиц из системного каталога не нужен:

Поэтому запустили pg_dump с параметром –data-only, чтобы выгрузить только данные. Утилита снова подвила. Снова проверили, что она делает, она выполняла тот же запрос. Разработчик (который под боком у Андрея) помог залогировать, что делает pg_dump. pg_dump выгружал не только списки таблиц, индексов, но и еще много совсем ненужного (расширенную статистику):

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

К этому времени СУБД простаивала уже сутки. Создали патч, чтобы запросы утилита pg_dump не выполняла. Поменять что-либо в СУБД не могли, так как DELETE и DROP подвисали. Данные скопировали в базы данных другого кластера. Только через сутки одна наиболее важную базу удалось выгрузить, загрузить в новый кластер и “оживить”.

По результатам Андрей оформил багрепорт ^[3] о том, что при отсутствии системных индексов pg_dump долго получает список таблиц

и приложил патч неизвестного разработчика из Postgres Pro, который сидел под боком и писал патчи. Жалко, что Андрей не назвал имя разработчика, так как созданный им патч качественный, понятный, неинвазивный, универсальный – подходит для 13-17 версий PostgreSQL.

В обсуждении бага Натан Боссарт отметил “Я не думаю, что это можно считать ошибкой ^[4], но избегать запросов pg_dump, когда это возможно, кажется хорошей идеей.” Том Лейн правильно отметил: “Нет оснований  полагать, что повреждение каталога преимущественно затрагивает индексы” Так и было – повреждения были рассыпаны во всех объектах, а не только в индексах. Одну базу частично выгрузили, а с частью баз приложение не смогло работать. Тома Лейна беспокоило то, что игнорирование объектов может привести к побочным эффектам если не в настоящем, то в будущем. Дэвид Роули попробовал переписать проблемный запрос, но не получилось.

Решать проблемы тех, кто не делает бэкапы, не имеет смысла, это только провоцирует увеличение числа таких администраторов. Администраторы должны знать, что без бэкапов (дампов, реплик) они не восстановят данные.

В результате всех телодвижений, компания, эксплуатировавшая разрушенный кластер баз данных, купила у Postgres Professional техническую поддержку enterprise уровня. Андрей Билле сказал, что именно так и должен выглядеть пресейл, но интуитивно почувствовав ментальное напряжение отдела пресейла, сделал оговорку, что, возможно, это и не так.

Андрей не сказал о том, прилагается ли энетерпрайз поддержка к энтерпрайз продукту или ее можно купить для бесплатной сборки. Если для бесплатной сборки, то у меня возник вопрос: чем энтерпрайз сборка лучше бесплатной. Поэтому, я думаю, была продана энтерпрайз сборка и уже к ней энтерпрайз техподдержка.

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

Ведущая: Будут ли у нас желающие задать вопросы? Боятся.

Докладчик: Ну не надо бояться.

Ведущая и докладчик: Есть, есть, бежим-бежим.

Голос из зала: Обнять и плакать.

Ведущая: Обнять и плакать, пожалуйста, в кулуарах.

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

– Большое спасибо за доклад. Действительно обнять и плакать.

И вот оно, отточенное движение самурая:

– А подскажите, пожалуйста, нельзя ли было заменить pg_dump на COPY?

Андрей Билле моментально всё понял и ответил: можно.

Это делает честь Андрею и быстроте его мышления ^[5].

Докладчик: Можно, можно, да, наверное, можно. Но вы поймите…

Самурай: но патч прикольнее

Докладчик: …то, что там 50000 таблиц только в одной базе. Ну да это можно было.

Самурай: можно было сгенерировать

Докладчик: да, можно было, конечно, скриптик, но, опять же, смогли бы мы, ну да… наверно, смогли бы…

Докладчик: Возможно, можно было, ну

Самурай: то есть, даже не влезая в это (системный каталог)

Докладчик: Да, даже не влезая в это. Да, возможно, можно было. Но тогда бы мы не нашли бы вот эту вот особенность pg_dumpа довольно-таки странную

Спарринг закончен, делается поклон:

Докладчик: да, согласен. Спасибо Вам.

Докладчик: Да, так можно было сделать это. Прекрасный (вопрос)

Участник на других докладах задавал вопросы, вопросы были профессиональными и показывали, что администратор быстро мыслит, глубоко разбирается в PostgreSQL, быстро схватывает суть.

Например, на утверждение ведущего доклада Александры Бондарь: “это счетчик buffer pin, ничего больше, это не счетчик ожиданий и не счетчик времени ожиданий”, участник сказал “ну скорость изменения счетчика”.

Ведущий попытался спорить: скорость изменения счетчика… это счетчик баффер-пинов, вы можете их не ждать их при этом, понимаете?

Участник: всё равно – скорость изменения.

Ведущий: скорость изменения – да, но она не гарантирует, что у вас есть проблема.

Участник прекрасно знает, что такое статистика и метрика (производная от статистики). Рост частоты закрепления блоков сам по себе укажет на проблему. Докладчик же немного “зомбирован” и придаёт событиям ожидания то, чего у них нет и из этого делая ложный вывод, что только waiteventsмогут указывать на проблемы. А дальше софизм: если событий ожидания нет, то якобы и проблем нет. Главное, не писать в pg-hackers о том, что usage count устарело, надо вставлять waitcount, а ещё лучше wait time, чтобы потом не расстраиваться, что сообщество с настороженностью относится к предложениям и патчам.

Вернёмся к докладу Андрея Билле. Антон Дорошкевич не согласился с результатом “спарринга” и взял микрофон:

Антон: Андрей, давай я дополню это чуть-чуть

Докладчик: Угу

Антон: Наверное, можно, но нельзя. Там 50 тысяч таблиц, неважно. 58 баз по десяткам тысяч таблиц. Проблема в том, что мы не имеем средств. Опа, батарейка кончается. Не могли средствами постгреса получить список таблиц.

Но позвольте, любому в зале было понятно, что выгружали –data-only, да и 1С хранит список таблиц у себя, о чём сказал докладчик.

Докладчик увещевает Антона: не, ну мы же его отключили, мы потом уже смотрим

Антон, подняв указательный палец вверх продолжил: Часами, на одну базу

У меня возникло впечатление ^[6], что Антон не понял, что в зале специалисты.

В мире PostgreSQL постоянно ведутся дискуссии и люди приходят к истине. Даже в примере обсуждения патча, предложенного Андреем, видно, что сообщество старается учесть всё – и патч дописывали и текст запроса меняли. Можно считать, что непринятие патча – проигрыш, но это закаляет и сподвигает делать патчи лучше или искать для патчей более актуальные проблемы. Например, ускорения поиска ссылки на актуальную версию строки в индексе типа btree. Никто не может выигрывать всё время. Ошибки позволяют развиваться, а ощущение побед или свита провоцируют снижение критического восприятия ^[9] (“головокружение от успехов”). То, что Антон говорил в микрофон дальше – не играет роли. Интеллект ^[10] надо применять не к оправданиям, ретроспективно, а в момент решения проблем. Даже если 1С хранит списки таблиц в бинарном виде, это не играет роли. Таблица pg_class – это тоже таблица. Если намеревались выгружать 50000 таблиц, то можно было бы начать с выгрузки содержимого pg_class и получить имена таблиц для команды COPY.

Но всё к лучшему, клиент купил техподдержку. Кроме наличия технической поддержки, по результатам устранения проблемы, полезно выписать для себя профильные рассылки или чаты, где можно задать вопросы пользователям, думаю отговорили бы от стирания WAL и подсказали бы идею с COPY. Для 1С есть профильный чат “PostgreSQL + 1C + Linux” с 4000 участников. Чат приносит пользу: в нём впервые была описана неприятная проблема с потоковым чтением в локальный буфер, появившаяся в 18 версии PostgreSQLhttps://habr.com/ru/companies/tantor/articles/1009548/ ^[11]

set effective_io_concurrency = 64;
create temp table t1 (a char(1700));
insert into t1 select 'a' from generate_series(1,20000);
create temp table t2 (a char(1700));
insert into t2 select * from t1;
SET
CREATE TABLE
INSERT 0 20000
CREATE TABLE
ERROR:  no empty local buffer available

Как быстро её исправит сообщество не знаю. Иронично, что с этой проблемой случилось наоборот: Induja Sreekanthan заполнил не баг-репорт, а пост в рассылку pg-hackers, а там много постов и он может затеряться.

Заключение

Не стоит эксплуатировать базу, в которой хранятся нужные данные без реплик, бэкапов или хотя бы дампов.

Если структура и набор таблиц нечасто меняется, то, на всякий случай, стоит иметь скрипт создания таблиц и других объектов, который создаёт утилита pg_dump с параметром –schema-only.

Стоит рассмотреть самые простые пути решения проблемы, а не менять ядро PostgreSQL.

Если в методичке Антона (из 12 пунктов) не упомянуты реплики и бэкапы, это не значит, что их не нужно делать. Например, другие специалисты  http://www.gilev.ru/pgbackup/ ^[12] пишут, что бэкапы важны:

Эта статья не обзор докладов конференции, как в статье про PGBootCamp ^[13]  Было много интересных докладов, которые стоит посмотреть самостоятельно. Я бы с удовольствием почитал обзор докладов, если бы кто-нибудь написал обзор. Но никто не пишет, так как на это требуется много времени (два дня, три зала) и это трудоёмко.

Участники PgConf могут посмотреть доклады по ссылке ^[14]. Если вы не участвовали в конференции, то можно посмотреть доклады PGBootCamp, они доступны для всех https://facecast.net/v/clients/pgbc2026msk.html ^[15] (нужно выбрать Поток, нажать на треугольник и запись докладов начнёт проигрываться).

Упомяну только, что был исправлен  неприятный баг в коде мультитранзакций, о котором полгода назад докладывал Андрей Бородин. Он же и был ведущим у доклада Дмитрия Юричева, который представил сообществу тесткейс, на котором возникал трудноуловимый, но неприятный баг. Компания Дмитрия натолкнулась на этот баг при реальной работе.

12 февраля 2026 года были выпущены минорные обновления, в которых баг был исправлен:

Дмитрий сказал: “Чем активнее мы будем тестировать на своих архитектурах, конфигурациях, тем качественнее будет наш PostgresSQL, поэтому делитесь своими находками, оптимизациями, новыми фичами, ну и, конечно, же багами.”