PGConf.Pоссия 2026

На примере собственноручно созданного инструмента PGHist расскажу, как отслеживать изменения в таблицах PostgreSQL через автогенерацию триггеров и процедур. Универсальное решение обеспечивает: историю для пользователя, аудит для анализа проблем и версионирование для отчётов. Покажу ключевые приёмы (лайфхаки) — момент фиксации транзакции, читабельная генерация кода и данные «до/после» в DDL-триггерах.

Провел сравнительное исследование поиска подстроки разными способами с использованием разных индексов и подходов к хранению. Хочу поделиться результатами.

В эпоху микросервисов и высоконагруженных систем традиционные подходы к интеграции с базами данных, такие как ORM, приводят к сложностям: ручной синхронизации схемы и кода, ошибкам совместимости и потере производительности. В докладе мы рассмотрим подход DB-first. Здесь база данных становится первичной — схема БД и SQL-запросы определяют контракт, а код для любого языка программирования генерируется автоматически со всевозможными проверками на корректность. Данный подход я реализовал в инструменте pGenie (https://pgenie.io). Я вывожу его в опенсорс и представлю в данной презентации.

Что общего между репликой, которая внезапно зависает в ожидании IPC/MultixactCreation, и командой MERGE, которая генерирует дублирующиеся значения? Оба случая — это редкие, но критические баги в PostgreSQL, которые годами оставались незамеченными. И оба были обнаружены одной командой инженеров, которые просто запустили синтетические тесты на своей инфраструктуре. В этом докладе пойдет рассказ о том, как мы столкнулись с необычными проблемами при использовании PostgreSQL 17, какие методы использовали для их воспроизведения, и как наши отчеты привели к крупным исправлениям в коде PostgreSQL:

1. Некорректные обновления в MERGE: Как команда MERGE в конкурентной среде могла генерировать дублирующиеся значения, нарушая монотонность последовательностей, и почему эта проблема была связана с неправильным использованием TM_FailureData.

2. Проблема с multixact на standby-сервере: Как репликация начинала зависать при высокой нагрузке с генерацией multixact ID, и почему это было связано с редким "corner case", который существовал потенциально с момента введения multitransactions.

Для кого: DBA, разработчики приложений с высокими требованиями к надежности, участники сообщества PostgreSQL.