В репозитории PostgreSQL появился тег REL_18_7, а разработчики подготовили примечания к обновлению с исправлениями ошибок, способных повредить индексы и резервные копии. Официальная публикация PostgreSQL 18.7 запланирована на 12 ноября 2026 года; уже сейчас документация показывает, какие установки могут потребовать дополнительных действий после обновления.
Ошибка параллельного pg_dump могла затронуть резервный сервер
Одна из самых серьёзных исправленных проблем связана с созданием резервной копии через pg_dump с несколькими параллельными процессами. Ошибку обнаружили при работе с резервным сервером PostgreSQL, который получает изменения с основного узла. При экспорте и последующем использовании снимка состояния базы мог повреждаться результат выгрузки и даже данные на резервном сервере.
Снимок состояния позволяет разным процессам видеть согласованную версию данных. При параллельной выгрузке это особенно важно: рабочие процессы должны читать одну и ту же логическую картину базы, несмотря на одновременные изменения. В описании исправления говорится и о более широком последствии — транзакция, импортировавшая снимок с резервного сервера, иногда возвращала неверные результаты.
Повреждённые GIN и GiST могли скрывать строки при поиске
В PostgreSQL 18.7 вошло несколько исправлений индексов GIN. Такие индексы часто используют для полнотекстового поиска и работы с данными JSON. Ранее при определённых обстоятельствах повреждённый индекс мог пропускать существующие строки или, напротив, указывать на посторонние записи. Из-за этого запрос возвращал неправильный результат без очевидной ошибки приложения.
Отдельное исправление касается индексов GiST, созданных расширением pg_trgm для поиска по похожим текстовым строкам. Ошибка могла приводить к пропуску подходящих совпадений. В документации к 18.7 прямо указана необходимость пересоздания затронутых индексов, в том числе использующих класс операторов gist_trgm_ops.
Есть и другой сценарий: после REINDEX CONCURRENTLY на внутренней TOAST-таблице последующие изменения индекса иногда терялись. Это могло проявляться сообщением missing chunk number при чтении больших значений. Для исправления уже затронутой таблицы документация описывает повторное построение её индексов.
Инкрементальные резервные копии потребуют новой точки отсчёта
Исправления затрагивают инкрементальное резервное копирование — способ сохранять изменения, произошедшие после предыдущей копии. Разработчики обнаружили несколько ситуаций, когда такие резервные копии могли оказаться повреждёнными.
Например, после переключения на новый основной сервер программа могла принять базовую копию из несовместимой истории журнала WAL. При объединении резервных копий это приводило к сохранению устаревших страниц. Ещё одна ошибка допускала неправильный порядок объединения сводок WAL, а определённая последовательность операций VACUUM могла восстановить некорректные сведения о видимости строк.
Поэтому в примечаниях к PostgreSQL 18.7 прежние инкрементальные файлы прямо названы ненадёжной основой. Для использующих этот механизм предусмотрено создание новой полной резервной копии после обновления, от которой будут отсчитываться последующие инкрементальные копии.
Ошибки планировщика и разделённых таблиц влияли на результаты запросов
В обновление включены изменения планировщика запросов — компонента PostgreSQL, который выбирает способ получения данных. Исправления касаются, среди прочего, запросов с LATERAL, внешних соединений, DISTINCT ON и некоторых условий сопоставления строк. В отдельных случаях старое поведение могло приводить к неверным результатам.
Поправки затронули и выбор разделов таблиц (partition pruning). Этот механизм позволяет читать только нужные части большой таблицы. Некоторые сочетания границ RANGE, разделов DEFAULT и конкурентных обновлений могли заставлять сервер пропускать строки, подходящие под условие запроса.
Обновление внутри ветки 18 не требует переноса всей базы
В документации указан обычный порядок перехода с PostgreSQL 18.x на 18.7: выгружать и заново восстанавливать всю базу или применять pg_upgrade не требуется. Достаточно обновления серверных файлов и перезапуска PostgreSQL в рамках процедуры обслуживания.
При этом исправление программного кода само по себе не восстанавливает индекс, который уже был повреждён. Для отдельных GIN, GiST pg_trgm, TOAST и B-tree на столбцах bpchar без указанной длины примечания предусматривают дополнительные операции REINDEX, если конфигурация подпадает под описанные условия. Требования зависят от типа индекса и конкретного проявления ошибки.
