E.24. Выпуск 15.1
Дата выпуска: 2022-11-10
В этот выпуск вошли различные исправления, внесённые после версии 15.0. За информацией о нововведениях версии 15 обратитесь к Разделу E.25.
E.24.1. Миграция на версию 15.1
Если используется версия 15.X, выгрузка/восстановление базы не требуется.
Однако если вы регулярно создаёте и удаляете таблицы больше 1 ГБ, обратите внимание на первый пункт в списке изменений.
E.24.2. Изменения
Устранение проблемы удаления сегментов больших таблиц, следующих за первым (Том Лейн) §
Вследствие нарушения логики удаления таблиц после этой операции все файлы, кроме первого, оставались на диске в случае удаления временных таблиц и в случае воспроизведения из WAL удаления обычных таблиц. В результате свободное место на диске могло быстро исчезать, если приложения регулярно создавали многогигабайтные временные таблицы.
Оставшиеся файлы временных таблиц удаляются при запуске процесса postmaster, поэтому для освобождения занимаемого ими места достаточно обновления до версии 15.1. Однако если во время использования версии 15.0 база данных отключалась аварийно и непосредственно перед таким отключением могли удаляться большие таблицы, рекомендуется проверить в каталогах базы данных файлы с именами вида
. Если файла с именемNNNN
.NN
(без суффиксаNNNN
.
) рядом нет, такие файлы следует удалить вручную.NN
Исправление обработки элементов
DEFAULT
в предложенииVALUES
с несколькими кортежами при добавлении данных в изменяемое представление (Том Лейн) §Следствием исправленного теперь упущения могли быть ошибки «cache lookup failed for type» (ошибка поиска в кеше для типа) или даже аварийный сбой в старых версиях.
Недопущение имени
_RETURN
для всех правил, кроме правилON SELECT
(Том Лейн) §Таким образом, задаваемое для представления правило
ON SELECT
будет отличаться от других задаваемых для него правил.Предотвращение сбоя в
EXPLAIN VERBOSE
для запроса, использующегоSEARCH BREADTH FIRST
с константами в качестве начальных значений (Том Лейн) §Запрещение использования команды
MERGE
для секционированной таблицы с секциями, являющимися сторонними таблицами (Альваро Эррера) §Этот сценарий не поддерживается, но раньше сообщение об этом было непонятным.
Корректировка формирования ограничений внешнего ключа для секций при выполнении
ALTER TABLE ATTACH PARTITION
(Жеан-Гийом де Рорте, Альваро Эррера) § §Ранее для добавляемой секции могли формироваться некорректные или повторяющиеся ограничения.
Устранение дефекта в планировщике при обращении к расширенной статистике по секционированным таблицам или таблицам с наследованием (Ричард Гуо, Джастин Призби) §
Ранее в некоторых случаях выдавалась ошибка «cache lookup failed for statistics object» (ошибка поиска в кеше для объекта статистики).
Исправление неверного порядка операций WAL при добавлении данных в индексы GIN по быстрому пути (Маттиас ван де Меент, Мингли Чжан) §
О негативном влиянии этого дефекта на работу ядра PostgreSQL неизвестно, но с некоторыми расширениями возникали проблемы.
Исправление ошибок в логическом декодировании при запуске воспроизведения с позиции между началом транзакции и началом подтранзакции (Масахико Савада, Хайато Курода) § §
Устранённые теперь ошибки могли приводить к сбоям проверочных утверждений в отладочных сборках или же к утечкам памяти.
Добавление точек, в которых возможно прерывание при логическом декодировании (Амит Капила, Масахико Савада) § §
Тем самым устраняются проблемы медленного отключения рабочих процессов репликации.
Предотвращение в рабочих процессах репликации попыток реплицировать данные секций в сторонние таблицы (Ши Юй, Том Лейн) §
Хотя сторонние таблицы могут быть секциями секционированных таблиц, реплицировать данные в такие секции в настоящее время нельзя. Ранее при попытке сделать это рабочий процесс логической репликации аварийно прерывался, а теперь он выдаёт ошибку.
Устранение сбоя рабочего процесса репликации в случае синтаксической ошибки в функции (Максим Орлов, Антон Мельников, Масахико Савада, Том Лейн) §
Если в команде
CREATE FUNCTION
илиDO
на языке SQL или PL/pgSQL была допущена синтаксическая ошибка, при выполнении этой команды рабочим процессом репликации он завершался аварийно из-за обращения по нулевому указателю или сбоя проверочного утверждения.Предотвращение двойного вызова обработчика завершения в модуле архивирования (Натан Боссарт, Бхарат Рупиредди) §
Добавление в планировщик проверки, предотвращающей обращения к таблице, для которой нет табличного метода доступа (Том Лейн) §
Это предотвращает сбой в некоторых случаях повреждения каталогов, например при использовании представления без правила
ON SELECT
.Предотвращение краха процесса postmaster при повреждении общей памяти (Том Лейн)
Предполагается, что повреждение общей памяти не должно быть критическим для процесса postmaster, он должен штатно перезапустить базу данных, но в одном месте кода были предприняты не все меры для этого.
Исправление сброса однострочного режима в libpq при конвейеризации (Денис Лаксельд) §
Флаг однострочной обработки не сбрасывался в нужный момент, если был активен конвейерный режим.
Исправление кода выхода psql при отмене запроса, заданного в командной строке (Питер Эйзентраут) §
Ранее команда
psql -c
сигнализировала об успешном завершении в случае отмены запроса. Теперь она будет возвращать ненулевой код, как и в случае других ошибок.запрос
Обеспечение возможности кроссплатформенного перемещения табличных пространств в pg_basebackup (Том Лейн) §
Теперь удалённый путь в
--tablespace-mapping
может задаваться как абсолютный путь и в стиле Unix, и в стиле Windows, поскольку ОС исходного сервера и локальной системы могут различаться.Устранение в pg_dump дефекта, из-за которого не выгружались комментарии, связанные с некоторыми ограничениями
CHECK
(Том Лейн) §Исправление команды
CREATE DATABASE
, позволяющее задатьoid
больше 231 (Том Лейн) §Вследствие устранённого теперь упущения утилита pg_upgrade не могла выполнить обновление, если в исходной инсталляции содержались базы с OID больше указанного значения.
Устранение обращения к освобождённой памяти в pg_stat_statements (Цигуй Чжао) §
Проблема возникала, когда в pg_stat_statements отслеживалась команда
ROLLBACK
, переданная по протоколу расширенных запросов. В отладочных сборках при этом гарантированно происходили сбои проверочных утверждений, а в обычных чаще всего никаких заметных негативных последствий не было, но если освобождённая память использовалась снова, это было чревато сохранением мусора в строке запроса.Устранение несовместимостей с LLVM 15 (Томас Манро, Андрес Фройнд) §
Добавление возможности использовать
__sync_lock_test_and_set()
для циклических блокировок на любой машине (Том Лейн) §Это упрощает перенос на новую машинную архитектуру, по крайней мере, если вы используете компилятор, поддерживающий эту встроенную в GCC функцию.
Переименование символа
REF
вREF_P
во избежание проблем при компиляции в последних версиях macOS (Том Лейн) §Исключение использования функции
sprintf
, чтобы во время компиляции не выдавались предупреждения о том, что она устарела (Том Лейн) §Обновление данных часовых поясов до версии tzdata 2022f, включающее изменение правил перехода на летнее время в Чили, Иране, Иордании, Мексике, Палестине, Сирии и на Фиджи, а также корректировку исторических данных для Чили, Крыма, Ирана и Мексики. §
Кроме того, пояс Europe/Kiev был переименован в Europe/Kyiv. Помимо этого, следующие пояса были включены в соседние, более популярные пояса, в которых время было таким же с 1970 г.: Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake и Pacific/Wallis. (Это косвенно влияет на пояса, ранее включённые в другие: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk и Pacific/Yap.) Пояса America/Nipigon, America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod и Europe/Zaporozhye также были включены в соседние, поскольку выяснилось, что заявления об отличиях этих поясов от соседних (после 1970 года) оказались ошибочными. Для всех этих поясов старое название сохранено в качестве альтернативного; фактически используются данные пояса, в который они были включены.
В результате такого включения для включённых поясов теряется история до 1970 г., что может вызвать проблемы в приложениях, рассчитывающих на согласованный вывод
timestamptz
. Например, хранимое значение1944-06-01 12:00 UTC
ранее для часового пояса Europe/Stockholm выводилось как1944-06-01 13:00:00+01
, а теперь будет выводиться как1944-06-01 14:00:00+02
.В принципе возможно собрать файлы часовых поясов так, чтобы были восстановлены данные старых поясов, но при этом будут добавлены и другие старые (и, как правило, плохо проверенные) данные поясов, что принесёт по сравнению с предыдущей версией больше изменений, чем просто принятие изменений из проекта tzdata. В PostgreSQL было решено включить в поставку рекомендованные данные tzdb, и насколько нам известно, производители большинства операционных системы поступают так же. Тем не менее, если эти изменения приводят к существенным проблемам в вашем приложении, возможным решением будет установка локальной сборки файлов с данными часовых поясов tzdb, полученной с указанием параметров для обратной совместимости (см. параметры
PACKRATDATA
иPACKRATLIST
).