E.5. Выпуск 14.9

Дата выпуска: 2023-08-10

В этот выпуск вошли различные исправления, внесённые после версии 14.8. За информацией о нововведениях версии 14 обратитесь к Разделу E.14.

E.5.1. Миграция на версию 14.9

Если используется версия 14.X, выгрузка/восстановление базы не требуется.

Однако если вы используете индексы BRIN, может быть целесообразно их перестроить; прочитайте вторую запись в списке изменений.

Если вы обновляете сервер с более ранней версии, чем 14.4, см. также Раздел E.10.

E.5.2. Изменения

  • Запрет замены имени схемы или владельца в скрипте расширения, если имя содержит кавычку, обратную косую черту или знак доллара (Ной Миш)

    Данное ограничение защищает от атак методом SQL-инъекций через доверенные расширения.

    Проект PostgreSQL благодарит Мику Гейтса, Валери Вулард, Тима Кэри-Смита и Кристофа Берга за сообщение об этой проблеме. (CVE-2023-39417)

  • Устранение путаницы в индексах BRIN между пустыми (без строк) зонами и зонами, заполненными NULL; исправление неправильного слияния сводок по зонам, заполненным NULL (Томаш Вондра)

    Каждое из этих упущений могло приводить к потере информации о том, что зона индекса BRIN содержала какие-либо значения NULL, так что последующие запросы, которые должны были возвращать NULL, не делали этого.

    Это исправление само по себе не корректирует ошибочные записи BRIN. Рекомендуется выполнить REINDEX для всех индексов BRIN, которые могут использоваться для поиска NULL.

  • Предотвращение ситуации, когда после прерывания команды DROP DATABASE база данных остаётся повреждённой, но доступной (Андрес Фройнд)

    Если команда DROP DATABASE прерывалась после того, как начала выполнять необратимые действия, целевая база данных оставалась доступной (поскольку происходил откат удаления её строки pg_database), но её содержимое повреждалось. Исправление такого поведения заключается в том, что база данных помечается как недоступная до начала выполнения необратимых операций. Последующий сбой данной команды оставит базу данных частично доступной, но единственно возможное действие для неё — выполнить ещё одну команду DROP DATABASE.

  • Обеспечение правильной пометки секционированных индексов как рабочих или нерабочих при их создании (Микаэль Пакье)

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

  • Игнорирование нерабочих дочерних индексов при сопоставлении секционированных индексов с дочерними во время выполнения ALTER TABLE ATTACH PARTITION (Микаэль Пакье)

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

  • Устранение возможной ошибки при пометке секционированного индекса как рабочего после присоединения всех его секций (Микаэль Пакье)

    При обновлении записи индекса в pg_index могли использоваться устаревшие данные для других столбцов. Одним из обнаруженных симптомов являлась ошибка «attempted to update invisible tuple» (попытка обновить невидимый кортеж).

  • Исправление ошибки в коде, из-за которой команда ALTER EXTENSION SET SCHEMA не всегда сообщала об ошибке, если расширение содержало какие-либо объекты за пределами схемы расширения (Микаэль Пакье, Хейкки Линнакангас).

    Команда ALTER EXTENSION SET SCHEMA должна возвращать ошибку, если расширение содержит объекты в нескольких схемах. Эта проверка была запрограммирована некорректно и в некоторых случаях не срабатывала, что приводило к непредсказуемому поведению.

  • Отключение использования частичных уникальных индексов для доказательства уникальности в планировщике (Дэвид Роули)

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

  • Отключение мемоизации соединений с подзапросом LATERAL с условиями соединения, содержащими изменчивые функции (Ричард Гуо)

    Мемоизация не должна применяться к подплану, содержащему условия с изменчивыми функциями, поскольку это может приводить к неправильным результатам запросов. Ранее проверка не учитывала некоторые случаи, связанные с использованием LATERAL.

  • Предотвращение создания некорректных планов для сторонних соединений с предложениями соединений, содержащими псевдоконстанты (Эцуро Фудзита)

    В настоящее время в планировщике отсутствует поддержка добавления предложений соединений, содержащих псевдоконстанты, к удалённому выносимому наружу соединению, поэтому данное исправление отключает создание удалённых соединений в таких случаях. (Более подходящее решение потребует кардинальных изменений структур данных планировщика, поэтому оно будет внесено в одной из следующих основных версий.)

  • Корректная обработка вложенных операторов SELECT для политик RLS и представлений с барьером безопасности при расширении действий правил (Том Лейн)

  • Устранение условий гонки при обнаружении конфликтов для режима изоляции SERIALIZABLE (Томас Манро)

    Конфликты могли не обнаруживаться при сканировании кучи по битовой карте, при использовании индексов GIN и при проверке изначально пустого индекса-B-дерева. Все эти случаи могли приводить к сбоям сериализуемости, поскольку некорректно допускалась фиксация конфликтующих транзакций.

  • Исправление поведения проверок EvalPlanQual для унаследованных или секционированных целевых таблиц (Том Лейн)

    Это упущение могло приводить к выполнению действий изменения или удаления в режиме изоляции READ COMMITTED, хотя их следовало пропускать из-за конфликтующих одновременных изменений.

  • Исправление хеш-соединения с внутренним хеш-ключом, содержащим параметры, которые поступают из внешнего вложенного цикла (Том Лейн)

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

  • Устранение периодических сбоев при попытке обновить поле столбца составного типа (Том Лейн)

    Если общее значение столбца составного типа было достаточно велико, чтобы потребовалось отдельное хранение значения TOAST, несвоевременная очистка кеша могла приводить к ошибкам или сбоям сервера.

  • Предотвращение утечек памяти на время срока действия запроса в некоторых запросах UPDATE с триггерами (Томаш Вондра)

  • Предотвращение утечек памяти на время срока действия запроса при повторном сканировании узла плана инкрементальной сортировки (Джеймс Коулман, Лауренц Альбе, Том Лейн)

  • Возможность передачи долей секунды в метод datetime() jsonpath (Том Лейн)

  • Предотвращение сбоев с переполнением стека при использовании очень сложных шаблонов текстового поиска (Том Лейн)

  • Добавление возможности использовать фрагменты длиной до 10240 байт в pg_hba.conf и pg_ident.conf (Том Лейн)

    Предыдущее ограничение в 256 байт оказалось недостаточным в некоторых случаях.

  • Исправление неправильной обработки условий нехватки памяти C++ (Хейкки Линнакангас)

    При использовании JIT нехватка памяти при вызове new в C++ вызывала критическую ошибку PostgreSQL вместо ожидаемого исключения C++.

  • Устранение редкого случая сбоя нулевого указателя в plancache.c (Том Лейн)

  • Предотвращение потери потенциально полезных сегментов общей памяти, когда освобождение страницы приводит к объединению диапазонов свободного пространства (Дунмин Лю)

    Сегмент перемещается в соответствующую «корзину» с учётом изменившегося объёма, чтобы его можно было найти при последующем поиске.

  • Возможность продолжения работы VACUUM после обнаружения определённых типов повреждения индекса-B-дерева (Питер Гейган)

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

  • Обеспечение снятия блокировки WrapLimitsVacuumLock после обнаружения в процессе очистки недопустимых данных в pg_database.datfrozenxid или pg_database.datminmxid (Андрес Фройнд)

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

  • Предотвращение двойного воспроизведения подготовленных транзакций во время восстановления после сбоя (suyu.cmj, Микаэль Пакье)

    Если происходил сбой во время выполнения контрольной точки с некоторыми уже записанными на диск данными о состоянии двухфазной транзакции, при восстановлении после сбоя подготовленные транзакции могли воспроизводиться дважды, что приводило к критической ошибке, такой как «lock is already held» (блокировка уже получена) в процессе запуска.

  • Исправление возможного сбоя во время повышения ведомого сервера при включённом архивировании и необходимости восстановления двухфазных транзакций (Джулиан Маркворт)

    Если необходимые двухфазные транзакции были записаны в самом последнем (частичном) сегменте журнала, повышение завершалось ошибкой с некорректным сообщением «requested WAL segment has already been removed» (запрошенный сегмент WAL уже удалён).

  • Обеспечение выполнения fsync для только что созданной, но пока пустой таблицы в следующей контрольной точке (Хейкки Линнакангас)

    Раньше функция fsync не вызывалась, и при сбое операционной системы пустой файл удалялся, в результате последующие операции с таблицей могли завершаться ошибкой «could not open file» (не удалось открыть файл).

  • Обеспечение внесения в журнал записи о создании слоя инициализации нежурналируемого индекса (Хейкки Линнакангас)

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

  • Добавление отсутствующих инициализаций флагов окончания задержки контрольной точки (suyu.cmj)

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

  • Исправление слишком строгого проверочного утверждения в коде jsonpath (Дэвид Роули)

    Данное проверочное утверждение не выполнялось, если в запросе применялся оператор .type() к результату like_regex. Проблема присутствовала только в сборках с проверочными утверждениями.

  • Предотвращение сбоя проверочного утверждения при обработке пустого оператора через расширенный протокол запросов в уже прерванной транзакции (Том Лейн)

  • Исправление обработки пустой строки функцией Soundex difference() в contrib/fuzzystrmatch (Александр Лахин, Том Лейн)

    Передача входной строки, не содержащей алфавитных символов, приводила к непредсказуемому результату.

  • Уточнение проверок пробельных символов во входных данных для contrib/hstore (Эван Джонс)

    В некоторых случаях символы ошибочно распознавались как пробельные и поэтому отбрасывались.

  • Запрет слишком больших входных массивов с классом операторов индекса gist__int_ops в contrib/intarray (Анкит Кумар Пандей, Александр Лахин)

    Раньше выдавалось сообщение NOTICE, но работа продолжалась, при этом создавалась неверная запись в индексе, что при чтении индекса могло приводить к сбою.

  • Предотвращение бесполезной двойной распаковки записей индекса GiST в contrib/intarray (Константин Книжник, Маттиас ван де Меент, Том Лейн)

  • Исправление работы функции gist_page_items() в contrib/pageinspect при наличии неключевых столбцов индекса (Александр Лахин, Микаэль Пакье)

    Ранее, если в индексе были неключевые столбцы, функция gist_page_items() не отображала эти значения на концевых страницах индекса или сразу аварийно завершала работу на внутренних страницах.

  • Исправление обработки pg_dump функций языка SQL нового стиля, тела которых требуют зависимостей от уникальных индексов при разборе запросов (Том Лейн)

    Такие функции обрабатывались некорректно при использовании предложений GROUP BY и ON CONFLICT. Функция должна была откладываться до появления уникального индекса в выводе дампа, но pg_dump этого не делал и вместо этого выдавал предупреждение «could not resolve dependency loop» (не удалось разрешить цикл зависимостей).

  • Обеспечение актуального состояния pg_index.indisreplident в записях кеша отношений (Шрути Говда)

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