E.10. Выпуск 16.5#

E.10. Выпуск 16.5
E.10. Выпуск 16.5
Назад НаверхПредметный указатель E. Заметки к релизуНачало Далее

E.10. Выпуск 16.5 #

E.10.1. Миграция на версию 16.5
E.10.2. Изменения

Дата релиза:  2024-11-14

Этот выпуск содержит различные исправления из версии 16.4. Для получения информации о новых функциях в основном выпуске 16 см. Раздел E.15.

E.10.1. Миграция на версию 16.5 #

Снятие дампа/восстановление не требуется для тех, кто использует 16.X.

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

Также, если вы обновляетесь с версии раньше, чем 16.3, смотрите Раздел E.12.

E.10.2. Изменения #

  • Убедитесь, что кэшированные планы помечены как зависящие от вызывающей роли, когда RLS применяется к ссылке на таблицу не верхнего уровня (Натан Боссарт) §

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

    Проект PostgreSQL благодарит Вольфганга Вальтера (Wolfgang Walther) за сообщение об этой проблеме. (CVE-2024-10976)

  • Заставить libpq отбрасывать сообщения об ошибках, полученные во время согласования протокола SSL или GSS (Джейкоб Чемпион) §

    Сообщение об ошибке, полученное до завершения переговоров по шифрованию, могло быть внедрено посредником, а не быть реальным выводом сервера. Сообщение об этом открывает дверь для различных угроз безопасности; например, сообщение может подделать результат запроса, который невнимательный пользователь может принять за правильный вывод. Лучшим решением кажется отбрасывание таких данных и полагание только на собственный отчет libpq о сбое подключения.

    Проект PostgreSQL благодарит Джейкоба Чемпиона за сообщение об этой проблеме. (CVE-2024-10977)

  • Исправлены непреднамеренные взаимодействия между SET SESSION AUTHORIZATION и SET ROLE (Tom Lane) § §

    Стандарт SQL предписывает, чтобы SET SESSION AUTHORIZATION имел побочный эффект в виде выполнения SET ROLE NONE. Наша реализация этого была ошибочной, создавая больше взаимодействия между двумя настройками, чем предполагалось. В частности, откат транзакции, в которой было выполнено SET SESSION AUTHORIZATION, приводил бы к возврату ROLE в NONE, даже если это не было предыдущим состоянием, так что эффективный идентификатор пользователя мог теперь отличаться от того, что было до транзакции. Временная установка session_authorization в функции SET имела аналогичный эффект. Связанная ошибка заключалась в том, что если параллельный рабочий проверял current_setting('role'), он видел none, даже когда должен был видеть что-то другое.

    Проект PostgreSQL благодарит Тома Лейна за сообщение об этой проблеме. (CVE-2024-10978)

  • Предотвращено изменение переменных окружения доверенным кодом PL/Perl (Эндрю Данстан, Ноа Миш) § § § § §

    Возможность манипулировать переменными окружения процесса, такими как PATH, дает злоумышленнику возможности для выполнения произвольного кода. Поэтому “доверенные” PL не должны предлагать такую возможность. Чтобы исправить plperl, замените %ENV на связанный хэш, который отклоняет любую попытку модификации с предупреждением. Недоверенный plperlu сохраняет возможность изменять окружение.

    Проект PostgreSQL благодарит Коби Абрамса за сообщение об этой проблеме. (CVE-2024-10979)

  • Исправлены обновления состояния каталога для ограничений внешнего ключа при присоединении или отсоединении разделов таблицы (Жан-Гийом де Рортэ, Тендер Ван, Альваро Эррера) § §

    Если ссылка на таблицу является разделенной, то для ссылающейся таблицы, которая является автономной, и для той, которая является разделом, требуются разные записи в каталоге. Команды ATTACH/DETACH PARTITION не смогли правильно выполнить это преобразование. В частности, после DETACH в теперь автономной таблице отсутствовали бы триггеры обеспечения внешнего ключа, что могло бы привести к тому, что в таблице позже появятся строки, не соответствующие ограничению внешнего ключа. Последующее повторное ATTACH также могло бы завершиться с неожиданными ошибками.

    Способ исправить это - выполнить ALTER TABLE DROP CONSTRAINT на теперь автономной таблице для каждого ошибочного ограничения, а затем заново добавить ограничение. Если повторное добавление ограничения не удалось, значит, вкрались некоторые ошибочные данные. Необходимо вручную восстановить согласованность между ссылающимися и ссылаемыми таблицами, затем заново добавить ограничение.

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

    SELECT conrelid::pg_catalog.regclass AS "constrained table",
       conname AS constraint,
       confrelid::pg_catalog.regclass AS "references",
       pg_catalog.format('ALTER TABLE %s DROP CONSTRAINT %I;',
                         conrelid::pg_catalog.regclass, conname) AS "drop",
       pg_catalog.format('ALTER TABLE %s ADD CONSTRAINT %I %s;',
                         conrelid::pg_catalog.regclass, conname,
                         pg_catalog.pg_get_constraintdef(oid)) AS "add"
FROM pg_catalog.pg_constraint c
WHERE contype = 'f' AND conparentid = 0 AND
   (SELECT count(*) FROM pg_catalog.pg_constraint c2
    WHERE c2.conparentid = c.oid) <>
   (SELECT count(*) FROM pg_catalog.pg_inherits i
    WHERE (i.inhparent = c.conrelid OR i.inhparent = c.confrelid) AND
      EXISTS (SELECT 1 FROM pg_catalog.pg_partitioned_table
              WHERE partrelid = i.inhparent));

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

  • Избегались возможные сбои и ошибки “не удалось открыть отношение” в запросах на секционированной таблице, происходящих одновременно с DETACH CONCURRENTLY и немедленным удалением секции (Álvaro Herrera, Kuntal Gosh) § §

  • ALTER TABLE ATTACH PARTITION запрещено, если таблица, которая должна быть присоединена, имеет внешний ключ, ссылающийся на секционированную таблицу (Álvaro Herrera) § §

    Такое расположение не поддерживается, и другие способы его создания уже не удаются.

  • Не использовались соединения или группировки по разделам, если сопоставление запроса для ключевого столбца не совпадало с сопоставлением ключа раздела (Jian He, Webbo Han) § §

    Такие планы могли привести к неправильным результатам.

  • Исправлена возможная ошибка “не удалось найти элемент pathkey для сортировки”, когда вывод запроса-члена UNION ALL должен быть отсортирован, и столбец сортировки является выражением (Андрей Лепихов, Том Лейн) §

  • Исправлены регрессии производительности, связанные с упрощением подзапросов под внешними соединениями, которые позже были сведены к простым соединениям (Tom Lane) §

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

  • Разрешено прерывание второй стадии построения индекса для больших хеш-индексов (Павел Борисов) §

  • Исправлена ошибка утверждения или запутывающее сообщение об ошибке для COPY (query) TO ..., когда query переписывается правилом DO INSTEAD NOTIFY (Tender Wang, Tom Lane) §

  • Исправлен сбой сервера, когда вызов json_objectagg() содержит изменяющуюся функцию (Amit Langote) §

  • Исправлена проверка уникальности ключей в конструкторах объектов JSON (Junwang Zhao, Tomas Vondra) §

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

  • Исправлено обнаружение перекошенных данных во время параллельного хеш-соединения (Томас Мунро) §

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

  • Запрещены имена локалей, содержащие не-ASCII символы (Томас Мунро) §

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

    Любой, кто сталкивается с новым сообщением об ошибке, должен либо создать новый дублированный локаль с именем, содержащим только ASCII, используя Windows Locale Builder, либо рассмотреть возможность использования имен локалей, соответствующих BCP 47, таких как tr-TR.

  • Исправлено состояние гонки при фиксации сериализуемой транзакции (Хейкки Линнакангас) §

    Неправильная обработка недавно зафиксированной транзакции могла привести к сбою утверждения или ошибке “не удалось получить доступ к статусу транзакции”.

  • Исправлено состояние гонки в COMMIT PREPARED, которое приводило к появлению осиротевших файлов 2PC (wuchengwen) §

    Одновременная команда PREPARE TRANSACTION могла привести к тому, что COMMIT PREPARED не удалял файл состояния двухфазной транзакции на диске для завершенной транзакции. Непосредственного негативного эффекта не было, но последующий сбой и восстановление могли завершиться неудачей с сообщением “не удалось получить доступ к статусу транзакции”, требуя ручного удаления осиротевшего файла для восстановления сервиса.

  • Избегались недопустимые обращения к памяти после пропуска недопустимого индекса toast во время VACUUM FULL (Tender Wang) §

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

  • Исправлены способы, которыми обновление каталога “на месте” могло быть потеряно (Ноа Миш) § § § § § § §

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

  • Сброс кэшей каталогов в конце восстановления (Ноа Миш) §

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

  • Избегалось использование параллельного запроса при удержании прерываний (Франческо Деграсси, Ноа Миш, Том Лейн) § §

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

  • Сообщен активный идентификатор запроса для статистических целей в начале обработки протокольных сообщений Bind и Execute (Сами Имсейх) §

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

  • Защита от переполнения стека в libxml2 с чрезмерно глубоко вложенным XML-вводом (Том Лейн, с благодарностью Нику Велльнхоферу) §

    Использовалась xmlXPathCtxtCompile() вместо xmlXPathCompile(), потому что последняя не защищала себя от рекурсии до переполнения стека в выпусках libxml2 до 2.13.4.

  • Исправлены некоторые проблемы с пробелами в результате XMLSERIALIZE(... INDENT) (Джим Джонс) §

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

  • Не игнорировалась параллельная REINDEX CONCURRENTLY, работающая с индексом с предикатами или выражениями (Михаил Николаев) §

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

  • Исправлено неправильное повторное разбор ORDER BY списков, когда возникает конфликт имен (Tom Lane) §

    Если элемент ORDER BY в SELECT является простым идентификатором, парсер сначала ищет его как имя выходного столбца SELECT для совместимости с SQL92. Однако, в ruleutils.c ожидается интерпретация SQL99, где такое имя является именем входного столбца. Таким образом, было возможно создать некорректное отображение представления в (довольно неразумном) случае, когда какой-то другой столбец переименовывается в выходном списке SELECT так, чтобы совпадать с входным столбцом, используемым в ORDER BY. Исправлено путем добавления квалификации таблицы для таких имен в выгруженном тексте представления.

  • Исправлены ошибки “не удалось найти план для подзапроса/CTE” в EXPLAIN (Ричард Гуо, Том Лейн) § §

    Этот случай возник при попытке вывести ссылки на поля результата типа RECORD подзапроса, когда подзапрос был полностью оптимизирован из плана (что возможно, по крайней мере, в случае, если он имеет условие WHERE с постоянным значением false). В плане ничего не остается для идентификации оригинальных имен полей, поэтому используется вывод fN для N-го столбца записи. (Это на самом деле правильное действие в любом случае, если вывод записи возник из конструктора ROW().)

  • Запретить USING выражение при изменении типа вычисляемого столбца (Петер Айзенраут) §

    У сгенерированной колонки уже есть выражение, определяющее содержимое колонки, поэтому включение USING не имеет смысла.

  • Игнорировались еще не определенные Portals в представлении pg_cursors (Tom Lane) §

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

  • Исправлен некорректный вывод представления pg_stat_io на 32-битных машинах (Бертран Друво) §

    Столбец временной метки stats_reset содержал мусор на таком оборудовании.

  • Предотвращено неправильное кодирование сообщений об ошибках “лишние символы после числового литерала” (Карина Лицкевич) §

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

  • Избежана ошибка “unexpected table_index_fetch_tuple call during logical decoding” при декодировании транзакции, включающей вставку значения по умолчанию для столбца (Takeshi Ideriha, Hou Zhijie) § §

  • Снижено потребление памяти при логическом декодировании (Масахико Савада) §

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

  • В рабочем процессе применения логической репликации гарантировалось, что прогресс происхождения не продвигается во время ошибки или завершения работы рабочего процесса применения (Хаято Курода, Швета Малик) §

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

  • Повторно отключена отправка статических (TLSv1.2) сессионных билетов (Даниэль Густафссон) §

    Предыдущее изменение для предотвращения отправки stateful (TLSv1.3) сессионных билетов случайно повторно включило отправку stateless. Таким образом, хотя предполагалось предотвратить у клиентов мысль о поддержке возобновления TLS-сессии, некоторые все же думали, что это поддерживается.

  • Избежано сбоя “неправильная длина кортежа” при удалении базы данных с множеством записей ACL (разрешений) (Айюш Тивари) § §

  • Разрешено изменение настроек session_authorization и role в параллельных рабочих процессах (Tom Lane) §

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

  • Исправлено поведение стабильных функций, вызываемых из списка аргументов оператора CALL, когда CALL находится внутри блока EXCEPTION PL/pgSQL (Tom Lane) §

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

  • Исправлены ошибки “не удалось найти функцию в кэше” в крайних случаях в CALL PL/pgSQL (Tom Lane) §

  • Исправлена потокобезопасность нашей резервной (не-OpenSSL) реализации MD5 на оборудовании с порядком байтов от старшего к младшему (Heikki Linnakangas) §

    Потокобезопасность в настоящее время не является проблемой на сервере, но она актуальна для libpq.

  • Параметр подключения libpq keepalives был разобран так же, как и другие параметры с целочисленными значениями (Юто Сасаки) §

    Кодирование, использованное здесь, отклонило завершающие пробелы в значении опции, в отличие от других случаев. Это оказалось проблематичным, например, в использовании ecpg.

  • Избегалось использование pnstrdup() в ecpglib (Джейкоб Чемпион) §

    Эта функция вызовет exit() при нехватке памяти, что нежелательно в библиотеке. Код, вызывающий функцию, уже правильно обрабатывает ошибки выделения.

  • В ecpglib исправлено чтение за пределами допустимого диапазона при разборе некорректного ввода даты и времени (Брюс Момджан, Павел Некрасов) §

    Было возможно попытаться прочитать местоположение непосредственно перед началом постоянного массива. Однако реальные последствия кажутся минимальными.

  • Исправлена утечка памяти в psql при повторном использовании \bind (Майкл Пакье) §

  • Избегание зависания, если интервал менее 1 мс указан в команде \watch в psql (Андрей Бородин, Майкл Пакье) §

    Вместо этого следует рассматривать это так же, как интервал нуля (без ожидания между выполнениями).

  • Исправлено pg_dump для обработки последовательностей идентификаторов, которые имеют устойчивость, отличающуюся от устойчивости их родительской таблицы (Tom Lane) §

    Начиная с версии 15, была возможность установить последовательность идентификаторов как LOGGED, когда ее владеющая таблица является UNLOGGED, или наоборот. Однако метод pg_dump для воссоздания этой ситуации не сработал в режиме бинарного обновления, что вызвало сбой pg_upgrade, когда такие последовательности присутствовали. Исправлено введением новой опции для ADD/ALTER COLUMN GENERATED AS IDENTITY, чтобы позволить правильно установить постоянство последовательности при создании. Обратите внимание, что это означает, что дамп из базы данных, содержащей такую последовательность, будет загружен только на сервер этой минорной версии или новее.

  • Включена история временной шкалы источника в отладочный вывод pg_rewind (Хейкки Линнакангас) §

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

  • Избегалось попыток переиндексации временных таблиц и индексов в vacuumdb и в параллельном reindexdb (VaibhaveS, Michael Paquier, Fujii Masao, Nathan Bossart) § § §

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

  • Разрешена инспекция последовательных отношений в соответствующих функциях contrib/pageinspect и contrib/pgstattuple (Натан Боссарт, Аюш Ватса) § §

    Это было разрешено в прошлом, но было нарушено при введении нестандартных методов доступа для таблиц.

  • Исправлен некорректный код, сгенерированный LLVM на платформах ARM64 (Томас Мунро, Антонин Боннефуа) §

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

  • Исправлены несколько мест, где предполагалось, что время начала процесса (представленное как time_t) будет помещаться в значение long (Макс Джонсон, Натан Боссарт) §

    На платформах, где long составляет 32 бита (особенно Windows), этот код не работал бы после 2038 года. Большинство сбоев казались бы только косметическими, но особенно pg_ctl start зависал бы.

  • Исправлена сборка с использованием Strawberry Perl на Windows (Эндрю Данстан) §

  • Обновлены файлы данных часовых поясов до tzdata релиза 2024b (Tom Lane) § §

    Этот выпуск tzdata изменил старые названия зон, совместимых с System-V, чтобы дублировать соответствующие географические зоны; например, PST8PDT теперь является псевдонимом для America/Los_Angeles. Основным видимым следствием является то, что для временных меток до введения стандартизированных часовых поясов зона считается представляющей местное среднее солнечное время для указанного местоположения. Например, в PST8PDT ввод timestamptz, такой как 1801-01-01 00:00, ранее отображался как 1801-01-01 00:00:00-08, но теперь отображается как 1801-01-01 00:00:00-07:52:58.

    Также внесены исторические исправления для Мексики, Монголии и Португалии. В частности, Asia/Choibalsan теперь является псевдонимом для Asia/Ulaanbaatar, а не отдельной зоной, главным образом потому, что различия между этими зонами были основаны на недостоверных данных.

Назад Наверх Далее
E.9. Выпуск 16.6 Начало E.11. Выпуск 16.4