PostgreSQL 15 в продакшне: первые недели после перевода боевого кластера

В октябре, когда вышел GA, мы написали про MERGE и row filtering - тогда это был разбор патчнотов и наблюдения со стейджинга. Сейчас у нас позади три недели с первым боевым кластером на PG 15, и картина немного другая: не то чтобы сюрпризы, но нюансы есть.

Коротко: ни один критический инцидент за три недели не связан с самим апгрейдом. Это, пожалуй, главный итог.

Что реально ощутили

MERGE вместо upsert-хаков. На этом кластере жил целый зоопарк паттернов INSERT ... ON CONFLICT DO UPDATE, завёрнутых в функции и триггеры. Часть из них делалась именно так, потому что нормальной альтернативы не было, часть - потому что "так исторически сложилось". После переезда переписали три самых громоздких места под MERGE. Код стал читаемым - буквально с первого взгляда понятно, что происходит при совпадении записи и что при вставке новой. Производительность примерно та же, зато меньше шансов что-то сломать при следующем рефакторинге.

Row filtering в логической репликации. Это отдельная история. У нас было несколько публикаций, где из большой таблицы нужна только часть строк - по статусу или по дате. Раньше делали это через промежуточные представления и отдельные таблицы-прослойки. Теперь в CREATE PUBLICATION можно передать WHERE-условие прямо на уровне публикации. Убрали одну лишнюю прослойку - и нагрузка на репликацию заметно снизилась: меньше данных гоняется по WAL-стриму туда, где они всё равно не нужны.

Сортировка с NULLS LAST по умолчанию в некоторых индексах. Это не новость PG 15 как таковая, но в процессе ревью кода под апгрейд нашли несколько мест, где порядок сортировки в индексе и в запросе молча расходился. PG 15 не менял поведение, просто апгрейд - хороший повод вычесать такие вещи.

Чеклист апгрейда - что у нас сработало

Ниже то, что реально делали, а не теоретический список из документации:

• pg_upgrade --check до начала - прогоняли дважды, на копии данных и на продакшн-реплике. На реплике нашёлся один extension с несовместимой версией (старый pg_stat_statements без пересборки).
• Тест расширений. Каждое расширение проверяли отдельно на стейджинге под PG 15. pg_partman, pgaudit, pg_cron - все поднялись без проблем. timescaledb потребовал отдельного обновления до совместимой версии до апгрейда СУБД.
• Анализ планов запросов. Запускали EXPLAIN (ANALYZE, BUFFERS) для топ-50 запросов по нагрузке на стейджинге PG 15 и сравнивали с PG 14. Два запроса получили другой план - один лучше, один хуже. Второй починили добавлением индекса.
• vacuum FULL и ANALYZE после апгрейда. Это в документации написано, но реально занимает время - закладывайте окно обслуживания с запасом.
• Откат. Держали PG 14 инстанс живым параллельно ещё неделю. Не понадобился, но знание что он есть - бесценно.
• Мониторинг логов первые 48 часов. Смотрели на pg_stat_activity, pg_stat_bgwriter, pg_stat_replication. Первые сутки были немного нервными.

Что не понравилось

Апгрейд через pg_upgrade с логической репликацией - это два отдельных действия, которые надо синхронизировать вручную. После pg_upgrade слоты логической репликации не переносятся - их надо пересоздавать, подписчиков переподключать. Ничего катастрофического, но это нетривиальный оркестр при большом числе подписчиков. Планировали заранее, отработали нормально, но лучше б это было проще.

Второй момент - pg_dump для некоторых объектов меняет порядок DDL в дампе. Если у вас есть скрипты, которые сравнивают дамп со "золотым эталоном" в репозитории - готовьтесь к ложным срабатываниям.

Что дальше

Следующий кластер - в феврале. Там сложнее: больше внешних подписчиков на логическую репликацию и несколько кастомных расширений. Уже прогнали pg_upgrade --check - пока чисто, но запас по времени для стейджинга берём больше.

Если у вас в работе задачи по DWH и базам данных - спрашивайте, опыт свежий.