Убедитесь, что кешированные планы помечены как зависящие от вызывающей роли, когда 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 могут завершиться неудачей, следует сохранить вывод запроса в файл, а затем попытаться выполнить каждый шаг.

Исправлен тест для C локали, когда LC_COLLATE отличается от LC_CTYPE (Джефф Дэвис) §

При использовании libc в качестве провайдера сортировки по умолчанию, тест на проверку использования локали C для сортировки случайно проверял LC_CTYPE, а не LC_COLLATE. Это не имело влияния в типичном случае, когда эти настройки совпадали, или если обе не были C (или ее псевдонимом POSIX). Однако, если LC_CTYPE была C, в то время как LC_COLLATE была другой локалью, могли возникнуть неправильные ответы на запросы, и была возможна порча индексов на строках. Пользователям баз данных с такими настройками следовало переиндексировать затронутые индексы после установки этого обновления. Обратный случай, когда LC_COLLATE была C, в то время как LC_CTYPE была другой локалью, вызвал бы снижение производительности, но не фактические ошибки.

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

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

Избегать сбоя планировщика после преобразования теста IS NULL на столбце NOT NULL в константу FALSE (Ричард Гуо) §

Эта ошибка обычно приводила к ошибкам, таким как “переменная не найдена в целевых списках подплана”.

Избегался возможный сбой планировщика при инлайнинге SQL-функции, аргументы которой содержат определенные конструкции, связанные с массивами (Том Лейн, Натан Боссарт) §

Исправлены возможные неправильные ответы или ошибки планировщика “wrong varnullingrels” для действий MERGE ... WHEN NOT MATCHED BY SOURCE (Дин Рашид) § §

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

Исправлен крайний случай в индексных сканированиях B-tree ScalarArrayOp (Питер Геогеган) §

Когда прокручиваемый курсор с таким планом был возвращён к своей начальной точке, а затем снова запущен вперёд, могли быть получены неправильные ответы.

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

Исправлена проверка опций FORCE_NOT_NULL и FORCE_NULL команды COPY (Joel Jacobson) §

Некоторые неправильные использования теперь отклонены, как и должно быть.

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

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

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

Избегать сбоя, когда ALTER DATABASE SET используется для установки серверного параметра, который требует поиска на основе пути поиска, такого как default_text_search_config (Джефф Дэвис) §

Избегались повторные обращения к классам операторов и колляциям при создании нового индекса на секционированной таблице (Tom Lane) §

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

Этот исправление также предотвращает копирование комментариев к родительскому секционированному индексу в дочерние индексы.

Добавлена отсутствующая зависимость от секционированной таблицы к нестандартному методу доступа, указанному в CREATE TABLE ... USING (Майкл Пакье) §

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Игнорировались еще не определенные Portals в представлении pg_cursors (Том Лейн) §

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

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

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

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

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

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

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

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

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

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

Исправлены команды описания psql, чтобы они снова работали с серверами до версии 9.4 (Tom Lane) §

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

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

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

Исправлена ошибка поиска пароля репликации в ~/.pgpass (Tom Lane) §

pg_basebackup и pg_receivewal не смогли сопоставить запись в ~/.pgpass, которая содержала replication в поле имени базы данных, если не был указан переключатель -d или --dbname. Это привело к неожиданному запросу пароля.

В pg_combinebackup была выдана ошибка, если файл инкрементального резервного копирования присутствовал в каталоге, который должен содержать полное резервное копирование (Роберт Хаас) §

В pg_combinebackup не создавались имена файлов, содержащие двойные слэши (Роберт Хаас) §

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

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

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

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

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

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

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

Обновлены файлы данных часовых поясов до 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, а не отдельной зоной, главным образом потому, что различия между этими зонами были основаны на недостоверных данных.