E.14. Выпуск 16.1#
E.14. Выпуск 16.1 #
Дата релиза: 2023-11-09
Этот выпуск содержит различные исправления из версии 16.0. Для получения информации о новых функциях в основном выпуске 16 см. Раздел E.15.
E.14.1. Миграция на версию 16.1 #
Снятие дампа/восстановление не требуется для тех, кто использует 16.X.
Однако было обнаружено несколько ошибок, которые могут привести к тому, что определенные типы индексов будут давать неправильные результаты поиска или будут неоправданно неэффективными. Рекомендуется выполнить REINDEX
потенциально затронутых индексов после установки этого обновления. См. четвертую по седьмую записи в журнале изменений ниже.
E.14.2. Изменения #
Исправлена обработка аргументов неизвестного типа в агрегатных функциях
DISTINCT
"any"
(Том Лейн) §Эта ошибка приводила к тому, что значение типа
text
интерпретировалось как значение типаunknown
(то есть, строка с нулевым окончанием) во время выполнения. Это могло привести к раскрытию памяти сервера после значенияtext
.Проект PostgreSQL благодарит Jingzhou Fu за сообщение об этой проблеме. (CVE-2023-5868)
Обнаружено переполнение целого числа при вычислении новых размеров массива (Tom Lane) §
При назначении новых элементов индексам массива, которые находятся за пределами текущих границ массива, в крайних случаях может не обнаружиться целочисленное переполнение. Возможны повреждения памяти, которые потенциально могут быть использованы для выполнения произвольного кода, а также раскрытие памяти сервера.
Проект PostgreSQL благодарит Педро Галлегоса, который сообщил об этой проблеме. (CVE-2023-5869)
Предотвращено, чтобы роль
pg_signal_backend
могла посылать сигналы фоновым рабочим и процессам автосборки (Ноа Миш, Йелте Феннема-Нио) § §В документации сказано, что
pg_signal_backend
не может посылать сигналы процессам, принадлежащим суперпользователю. Однако он мог посылать сигналы этим фоновым процессам, потому что они показывают роль OID, равную нулю. Это рассматривалось как указание на владение суперпользователем. Последствия для безопасности при отмене одного из этих типов процессов незначительны, насколько это касается основного кода (просто запускается другой процесс), но расширения могут добавлять фоновые рабочие процессы, которые более уязвимы.Настроена проверка корректности настройки
is_superuser
в таких процессах. Какие-то конкретные последствия для безопасности не известны, но это может быть важно для некоторых расширений.Проект PostgreSQL благодарит Хеманта Сандрану (Hemanth Sandrana) и Махендракара Сриивасарао (Mahendrakar Srinivasarao) за сообщение об этой проблеме. (CVE-2023-5870)
Исправлено неправильное поведение при рекурсивном разделении страницы в построении индекса GiST (Хейкки Линнакангас) §
Исправлена ситуация, когда местоположение ссылки на страницу отслеживалось неправильно, и введена логика, позволяющая восстанавливаться из таких ситуаций, а не выполнять неправильные действия без предупреждений. Эта ошибка могла привести к неправильным ответам при последующих поисках в индексе. Возможно, будет целесообразно переиндексировать все индексы GiST после установки этого обновления.
Предотвращена де-дупликация записей индекса btree для столбцов
interval
(Ноа Миш) §Есть значения
interval
, которые различимы, но которые сравниваются как равные, например24:00:00
и1 day
. Это нарушает предположения, сделанные при удалении дубликатов btree, поэтому столбцы типаinterval
необходимо исключить из процесса удаления дубликатов. Этот недочет может привести к неправильным результатам при сканировании только по индексам. Более того, после обновления amcheck будет выдавать ошибку почти для всех подобных индексов. Пользователям следует переиндексировать любые индексы btree на столбцах типаinterval
.Обработка значений
date
более разумно в BRINdatetime_minmax_multi_ops
индексах (Tomas Vondra) §Расчет расстояния между значениями дат был обратным, что приводило к неверным решениям о том, какие записи объединять. Индекс выдавал правильные результаты, но работад менее эффективно, чем должен. Рекомендуется переиндексация индексов BRIN
minmax_multi
на столбцахdate
.Обработаны большие значения
timestamp
иtimestamptz
более разумно в BRINdatetime_minmax_multi_ops
индексах (Tomas Vondra) § §Бесконечности ошибочно рассматривались как имеющие нулевое расстояние, а не большое расстояние от других значений, что приводило к неправильным решениям о том, какие записи объединять. Также конечные, но очень большие значения (близкие к границам диапазона представимых меток времени) могли приводить к внутренним переполнениям, что снова вызывало неправильные решения. Индекс по-прежнему выдавал правильные результаты, но работал менее эффективно, чем должен. Рекомендуется переиндексация BRIN
minmax_multi
индексов на столбцахtimestamp
иtimestamptz
, если столбец содержит или содержал бесконечности или большие конечные значения.Избегались переполнения вычислений в BRIN
interval_minmax_multi_ops
индексах с экстремальными значениями интервалов (Tomas Vondra) §Эта ошибка могла вызвать неожиданные сбои при попытке вставить большие значения интервала в такой индекс.
Исправлена генерация шагов секционирования и времени отсечения секций для таблиц с несколькими ключами разделения, секционированных по хешу (Дэвид Роули) § §
Некоторые случаи, связанные с условием
IS NULL
на одном из ключей секции, могут привести к сбою.Исправлено несоответствующее повторное проверение одновременно обновленных строк во время
MERGE
(Дин Рашид) §В режиме
READ COMMITTED
обновление, которое обнаруживает, что его целевая строка была только что обновлена параллельной транзакцией, будет повторно проверять условия запросаWHERE
на обновленной строке.MERGE
не обеспечивал использование правильных строк других соединенных таблиц во время этой повторной проверки, что могло привести к неправильным решениям о том, должна ли вновь обновленная строка быть обновлена снова с помощьюMERGE
.Правильно определена целевая таблица в унаследованном
UPDATE
/DELETE
/MERGE
, даже когда родительская таблица исключена из-за ограничений (Амит Ланготе, Том Лейн) § § §Если изначально указанная таблица исключена из-за ограничений, но не все её наследники исключены, то первым не исключённым наследником определялась основная целевая таблица. Это приводило к срабатыванию триггеров на уровне операторов, связанных с этой таблицей, а не с изначально указанной таблицей, как должно быть. В версии 16, тот же недочет мог также привести к ошибкам “недопустимый perminfoindex 0 в RTE с relid NNNN”.
Исправлен крайний случай в обработке mark/restore btree для выражений ScalarArrayOpExpr (Питер Геогеган) §
При восстановлении indexscan на ранее отмеченную позицию, код мог пропустить необходимые шаги настройки, если сканирование продвинулось точно до конца совпадений для ScalarArrayOpExpr (то есть,
indexcol = ANY(ARRAY[])
) условия. Это могло привести к пропуску некоторых строк, которые должны были быть извлечены.Исправлена утечка памяти внутри запроса в выполнении Memoize (Орлов Алексей, Дэвид Роули) §
Исправлена утечка памяти внутри запроса, когда функция, возвращающая набор, многократно возвращает ноль строк (Tom Lane) §
Не произошел сбой, если
cursor_to_xmlschema()
был применен к порталу, не возвращающему данные (Бою Ян) §Исправлено неправильное использование условия фильтрации источника между последовательными вызовами
pg_logical_slot_get_changes()
(Hou Zhijie) §Условие происхождения, установленное одним вызовом этой функции, будет повторно использоваться последующими вызовами, которые не указали аргумент происхождения. Это не было предусмотрено.
Выброшена предполагаемая ошибка, если
pgrowlocks()
применяется к секционированной таблице (Дэвид Роули) §Ранее возникала жалоба “поддерживается только heap AM”.
Более аккуратно обработаны недопустимые индексы в различных SQL функциях (Ноа Миш) §
Настроено выведение сообщения об ошибке, если
pgstatindex()
,pgstatginindex()
,pgstathashindex()
илиpgstattuple()
применяется к недопустимому индексу. Еслиbrin_desummarize_range()
,brin_summarize_new_values()
,brin_summarize_range()
илиgin_clean_pending_list()
применялось к недопустимому индексу, выдавалось только сообщение отладочного уровня. Ранее эти функции пытались обработать индекс и могли завершиться неудачей странными способами в зависимости от результата невыполненной командыCREATE INDEX
.Избегайте преждевременного отказа выделения памяти при длинных вводах в
to_tsvector()
(Tom Lane) §Исправлено чрезмерное выделение памяти для сконструированного
tsvector
вtsvectorrecv()
(Денис Ерохин) §Если входящий вектор включает данные о позиции, функция двоичного приема оставляет неиспользованное пространство (примерно равное размеру данных о позиции) в готовом
tsvector
. В крайних случаях это могло привести к ошибкам “превышена максимальная общая длина лексемы” для векторов, которые были в пределах допустимой длины при создании. В любом случае это могло привести к неиспользованному пространству на диске.Улучшены проверки на поврежденные данные, сжатые с помощью PGLZ (Флавьен Гедез) §
Исправлено
ALTER SUBSCRIPTION
так, чтобы запрашиваемое изменение в опцииrun_as_owner
действительно применялось (Hou Zhijie) §Исправлена массовая вставка таблицы в секционированные таблицы (Andres Freund) §
Неправильное совместное использование состояния вставки между секциями могло привести к сбоям во время
COPY FROM
, обычно проявляющимся как ошибки “не удалось прочитать блок NNNN в файле XXXX: прочитано только 0 из 8192 байт”.В
COPY FROM
избегалась оценка значений по умолчанию для столбцов, которые не будут нужны командой (Лауренц Альбе) §Это позволяло избежать возможной ошибки, если значение по умолчанию на самом деле не было допустимым для столбца, или если выражение по умолчанию не удалось бы в текущем контексте выполнения. Такие крайние случаи иногда возникали при восстановлении дампов, например. В предыдущих версиях ошибка в этой ситуации не возникала, поэтому предотвращено возникновение ошибки в v16.
В
COPY FROM
произошел чистый сбой, когда требовалась неподдерживаемая конвертация кодировки (Tom Lane) §Недавний рефакторинг случайно удалил предусмотренную проверку ошибок в этом случае, так что выдавалось сообщение “cache lookup failed for function 0”, вместо информативного сообщения об ошибке.
Избегать сбоя в
EXPLAIN
, если параметр, помеченный для отображенияEXPLAIN
, имеет значение NULL во время загрузки (Xing Guo, Aleksander Alekseev, Tom Lane) §Ни один встроенный параметр не соответствует этому описанию, но расширение может определить такой параметр.
Убедиться, что снимок был сделан при удалении временных таблиц
ON COMMIT DROP
(Том Лейн) §Это предотвращает возможное неправильное поведение, если какие-либо записи каталога для временных таблиц имеют поля, достаточно широкие, чтобы требовать использования toasting (например, очень сложное
CHECK
условие).Избегалась неправильная реакция на сигналы завершения в дочерних процессах, только что созданных с помощью
system()
(Натан Боссарт) §Это исправление устраняет условия гонки, при котором дочерний процесс, который был порожден с помощью
system()
, но еще не выполнил exec для запуска дочерней программы, может получить и обработать сигнал, предназначенный для родительского серверного процесса. Это приведет к выполнению дублирующих действий по очистке, что не приведет ни к чему хорошему.Справляться с разорванными чтениями
pg_control
в программах фронтенда (Томас Манро) §На некоторых файловых системах чтение
pg_control
может не быть атомарным действием, когда сервер одновременно записывает этот файл. Это можно обнаружить через неверный CRC. Попробуйте несколько раз, чтобы увидеть, станет ли файл допустимым, прежде чем мы сообщим об ошибке.Избегались разорванные чтения
pg_control
в соответствующих SQL функциях (Томас Мунро) §Настроено получение блокировки перед чтением
pg_control
, чтобы обеспечить согласованное представление этого файла.Исправлены ошибки “не удалось найти элемент pathkey для сортировки”, возникающие при планировании агрегатных функций с опциями
ORDER BY
илиDISTINCT
(Дэвид Роули) §Избежано переполнения целого числа при вычислении размера массива строк активности серверного процесса (Jakub Wartak) §
На 64-разрядных машинах допустимы достаточно большие значения
track_activity_query_size
, которые могут вызвать 32-разрядное переполнение при умножении на допустимое количество подключений. Однако код, фактически выделяющий локальный массив для каждого бэкенда, работал некорректно и выделял массив неправильно.Исправлено кратковременное отображение несогласованной статистики прогресса для
ANALYZE
на унаследованных таблицах (Хейки Линнакангас) §Счетчики на уровне блока должны быть сброшены до нуля одновременно с обновлением поля текущего отношения.
Исправлено, чтобы фоновый писатель сообщал о любых записях WAL, которые он делает, в счетчики статистики (Назир Билал Явуз) §
Исправлено недоразумение относительно поведения принудительной очистки в
pgstat_report_wal()
(Рёга Ёсида, Майкл Пакье) §Это могло приводить к тому, что некоторые статистические данные о вводе-выводе WAL будут забыты при завершении работы.
Исправлено отслеживание статистики расширений временных таблиц (Карина Лицкевич, Андрес Фройнд) §
Эти операции были посчитаны как записи в обычные таблицы, когда они должны были быть посчитаны как записи во временные таблицы.
Когда
track_io_timing
включен, время, затраченное на операции расширения отношений, включено в время записи (Назир Билал Явуз) §Отслеживались зависимости кэшированных операторов
CALL
, и они перепланировались при необходимости (Tom Lane) §Команды DDL, такие как замена функции, которая была встроена в аргумент
CALL
, могут создать необходимость повторного планированияCALL
, который был кэширован PL/pgSQL. Это не происходило, что приводило к неправильному поведению или странным ошибкам, таким как “не удалось найти в кэше”.Избегался возможный сбой pfree-a-NULL-pointer после ошибки в настройке соединения OpenSSL (Сергей Шиндерюк) §
Глубина вложенности отслеживалась корректно при проверке
RECORD
-типа переменных из внешних уровней запроса (Ричард Гуо) §Этот недочет мог приводить к сбоям утверждений, дампам ядра или ошибкам “некорректный varno”.
Отслеживались зависимости хеш-функции и функции-негатора плановых узлов ScalarArrayOpExpr (Дэвид Роули) §
В большинстве случаев этот недочет был безвреден, так как эти функции вряд ли исчезнут, пока исходный оператор узла остается присутствующим.
Исправлена ошибка обработки ошибок в управлении кэшем типа
RECORD
(Томас Мунро) §Ошибка нехватки памяти, произошедшая в неподходящий момент, может оставить неконсистентное состояние, которое приведет к бесконечному циклу.
Сбой из-за нехватки памяти при чтении WAL рассматривался как фатальный (Майкл Пакье) §
Ранее это рассматривалось бы как «недопустимые данные», что приводило к выводу сообщения о достижении конца WAL, что является неверным и могло бы привести к некорректному воспроизведению WAL.
Исправлена возможная ошибка восстановления из-за попытки выделить память на основе ложного поля длины записи WAL (Томас Мунро, Майкл Пакье) § §
Исправлена ошибка “не удалось дублировать дескриптор”, возникающая в Windows, когда
min_dynamic_shared_memory
установлена выше нуля (Thomas Munro) §Исправлен порядок операций в
GenericXLogFinish
(Джефф Дэвис) §Этот код нарушал условия безопасности при сбоях, записывая WAL до того, как пометить измененные буферы как грязные. Основной код не использует эту функцию, но расширения используют (
contrib/bloom
, например).Удалено некорректное утверждение в обработке исключений PL/Python (Александр Лахин) §
Исправлено pg_dump для дампа новой опции
run_as_owner
подписок (Филип Уорнер) §Из-за этого упущения подписки всегда восстанавливались с
run_as_owner
установленным вfalse
, что не эквивалентно их поведению в выпусках до v16.Исправлено pg_restore, чтобы выборочные восстановления включали как ACL на уровне таблицы, так и ACL на уровне столбца для выбранных таблиц (Эйлер Тавейра, Том Лейн) §
Ранее восстанавливался бы только ACL на уровне таблицы, если бы оба типа присутствовали.
Добавлена логика в pg_upgrade для проверки использования типов данных
abstime
,reltime
, иtinterval
(Álvaro Herrera) §Эти устаревшие типы данных были удалены в версии PostgreSQL 12, поэтому убедитесь, что они отсутствуют в старой базе данных, прежде чем утверждать, что её можно обновить.
Избежаны ложные ошибки “слишком много клиентских подключений” в pgbench на Windows (Ноа Миш) §
Исправлено vacuumdb для обработки нескольких переключателей
-N
(Натан Боссарт, Кувамура Масаки) §Несколько переключателей
-N
должны были исключать таблицы в нескольких схемах, но на самом деле ничего не исключали из-за ошибочной конструкции сгенерированного запроса.Исправлено vacuumdb, чтобы учитывался его параметр
--buffer-usage-limit
в режиме только анализа (Рёга Ёсида, Дэвид Роули) §В
contrib/amcheck
не сообщалось об прерванном удалении страницы как о повреждении (Ноа Миш) §Это исправление предотвращает ложные срабатывания сообщений “первый дочерний элемент самой левой целевой страницы не является самым левым на своем уровне”, “блок NNNN не является самым левым” или “левая ссылка/правая ссылка в индексе XXXX не совпадают”. Они появлялись, если amcheck запускался после незавершенного удаления страницы индекса btree и до того, как
VACUUM
завершал очистку.Исправлена ошибка индексов
contrib/btree_gin
на столбцах типаinterval
, когда выполнялся индексный скан с использованием оператора<
или<=
(Дин Рашид) §Такой индексный скан не смог вернуть все записи, которые должен был.
Добавлена поддержка LLVM 16 и 17 (Томас Мунро, Дмитрий Долгов) § § §
Подавлены различные предупреждения времени сборки на последних версиях macOS (Tom Lane) § §
Xcode 15 (выпущенный с macOS Sonoma) изменил поведение компоновщика таким образом, что вызывается множество предупреждений о дублировании библиотек при сборке PostgreSQL. Эти предупреждения были безвредными, но раздражающими, поэтому избегайте указания одних и тех же библиотек дважды. Также удалено использование переключателя компоновщика
-multiply_defined suppress
, который, по-видимому, долгое время был неактивен, и теперь вызывает активные жалобы.При создании файла правил
contrib/unaccent
, использовалсяpython
, если--with-python
не был указан и переменная makePYTHON
не была установлена (Japin Li) §PHOT
(время Фениксских островов) удалено из списка аббревиатур часовых поясов по умолчанию (Tom Lane) §Наличие этой аббревиатуры в списке по умолчанию могло вызвать сбои на последних версиях Debian и Ubuntu, так как они больше не устанавливают соответствующую запись tzdb по умолчанию. Поскольку это вымышленная аббревиатура для зоны с общим населением около двух десятков человек, маловероятно, что кто-то заметит её отсутствие. Если кто-то всё же заметит, они могут добавить её с помощью пользовательского файла аббревиатур.