Обновление версий PostgreSQL, или Как не уронить базу при update?

Мы решили поделиться памяткой (чеклистом) нашей команды по обновлению PostgreSQL. В ней мы отметили взяли за основу фичи, представленные в release официальной документации PostgreSQL и провели анализ на предмет нарушения совместимости и кому стоит обратить внимание на обновленный функционал.

Меня зовут Александр Коцюруба, я руковожу разработкой внутренних сервисов в компании DomClick.ru.

Статья разбита на части с заголовками. Каждый заголовок относится к обновлению PostgreSQL с одной версии на другую. В рамках каждой главы мы выделили:

- Фича
- Риск, который может повлечь потенциальная несовместимость
- - Нарушение работы приложения
- - Падение производительности
- Кому обратить внимание при обновлении
- - Системный администратор
- - Разработчик
- Комментарий

Итак, начнем.

Способы обновления

pg_upgrade — не самый надежный способ обновления PostreSQL. Например, вы можете получить ошибку при проведении REINDEX'a предыдущей версии PostgreSQL.
logical replication — звучит заманчиво, так как позволит свести downtime при обновлении до минимума. Но, logical replication появилось только в 10. Теоретический для этой цели можно использовать pglogical (от 2ndquadrant), он поддерживает версии от 9.4 до 12. Поэтому, если вы используете PostgreSQL<10.0, данное расширение может быть полезно.
pg_dumpall — проверенный способ. Недостаток — на больших БД будет большой downtime.
pg_dumpall --globals-only с последующим pg_dump --create. На наш взгляд, более предпочтительный метод, чем предыдущий, для обновления кластеров PostgreSQL.

PostgreSQL 9.5 -> 9.6

Фича	Риск	Кому обратить внимание	Комментарий
^{В функции to_char() знак минус не должен считаться частью поля с заданной шириной для компонентов времени (Брюс Момджян) Например, to_char('-4 years'::interval, 'YY') теперь возвращает -04, а не -4.}	^{Нарушение работы приложения}	^{Разработчик}	^{Если кто-то использует to_char() вместе с отрицательными значениями, то необходимо проверить и исправить.}
^{Более разумное поведение функции extract() с бесконечными значениями в аргументах (Виталий Буровой) Ранее функция extract() просто возвращала ноль для аргумента «бесконечность», вне зависимости от выбранного поля. Теперь она будет возвращать infinity или -infinity соответственно, когда это поле является монотонно возрастающим (например, year, epoch), и NULL в противном случае (например, day, hour). Также теперь выдаётся ожидаемая ошибка при некорректном указании поля.}	^{Нарушение работы приложения}	^{Разработчик}	^{Если используется extract() вместе c бесконечным значением времени, то необходимо исправить.}
^{Добавление в pg_stat_activity информации о том, чего ждёт процесс (Амит Капила, Ильдус Курбангалиев) Исторически процесс показывался как ожидающий, только если он ожидал тяжёлой блокировки. Теперь в pg_stat_activity также показываются ожидания лёгких блокировок и закреплений буферов. Также теперь виден тип ожидаемой блокировки. В результате этих изменений столбец waiting был заменён столбцами wait_event_type и wait_event.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Бизнес-логику не затронет. Важно для программ мониторинга.}
^{Исправление стандартного анализатора текстового поиска, чтобы он принимал начальные цифры во фрагментах текста типа email и host (Артур Закиров) В большинстве случаев это не должно отразиться на разборе текста, но если вы часто имеете дело с такими адресами, может иметь смысл перестроить зависимые столбцы и индексы tsvector, чтобы адреса этих видов корректно находились при поиске.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Сделали поддержку почты и имен хостов, начинающихся с цифр, для парсера полнотекстового поиска. После обновления PostgreSQL не забудьте пересобрать индексы полнотекстового поиска. Но если делать через pg_dump, то таких проблем не будет. Т.е. это еще аргумент не в пользу pg_upgrade.}
^{Ликвидация давно считавшихся устаревшими указаний CREATEUSER/NOCREATEUSER команды CREATE ROLE и родственных ей (Том Лейн) Указание CREATEUSER на самом деле означало SUPERUSER из давних соображений относительно обратной совместимости. Это постоянно вводило в заблуждение людей, которые полагали (и имели на это право), что оно означало CREATEROLE. Это указание считается устаревшим уже десять лет, так что пора решить эту проблему, убрав его.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Убрали функцию, которая устарела задолго до выхода 9.6.}
^{Считать имена ролей, начинающиеся с pg_, зарезервированными (Стивен Фрост) Теперь пользователям будет запрещено создавать роли с такими именами. Это предотвращает конфликты со встроенными ролями, создаваемыми программой initdb.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Параметр psql -c теперь не подразумевает поведение параметра --no-psqlrc (Павел Стехуле, Каталин Якоб) Для получения старого поведения нужно явно написать --no-psqlrc (или сокращение -X). Модифицированные таким образом скрипты будут продолжать работать и со старыми версиями psql.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Возможны сбои при работе через psql.}
^{Improve pg_restore's -t option to match all types of relations, not only plain tables (Craig Ringer)}	^{Нарушение работы приложения}	^{Системный администратор}
^{Изменение формата отображения NextXID в pg_controldata и связанных местах (Джо Конвей, Брюс Момджян) Отображение значений эпоха-и-ID-транзакции в формате число: число. Предыдущий формат число/число был похож на формат LSN, что могло вводить в заблуждение.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Функции расширений, для которых это уместно, помечены как безопасные для распараллеливания (Андреас Карлссон) Во многие стандартные расширения внесены изменения, чтобы их функции могли выполняться параллельными исполнителями запросов. Эти изменения не вступят в силу в базах данных, обновлённых с предыдущих версий (с помощью pg_upgrade), пока вы не примените для каждого такого расширения команду ALTER EXTENSION UPDATE (в каждой базе данных кластера).}	^{Нарушение работы приложения}	^{Системный администратор}	^{После использования pg_upgrade нужно будет обновить все extension. Еще один аргумент не в пользу pg_upgrade}

Интересная фича

Возможность аннулирования старых снимков MVCC после настраиваемого промежутка времени (Кевин Гриттнер)

Обычно удалённые кортежи не могут быть ликвидированы физически при очистке, пока не будет отработана последняя транзакция, в которой они могут быть видны. Транзакция, остающаяся открытой в течение долгого времени, может стать причиной значительного замусоривания таблицы, препятствуя освобождению места. Это средство позволяет задать с помощью нового конфигурационного параметра old_snapshot_threshold ограничение времени, в течение которого снимок MVCC будет гарантированно актуальным. По истечении этого времени мёртвые кортежи могут быть удалены. Транзакция, использующая просроченный снимок, получит ошибку, если она попытается прочитать страницу, которая могла бы содержать такие данные.

Решает проблему «раздутия» БД по причине «открыл транзакцию и ушел в отпуск»; необдуманных апдейтов, которые занимают часы; долгих select как на master, так и на slave. Это одна из двух опций, благодаря которой можно будет решить проблему, из-за которой не могут перегрузить долгие запросы с master на slave.

PostgreSQL 9.6 -> 10.0

Фича	Риск	Кому обратить внимание	Комментарий
^{После обновления с помощью pg_upgrade с любой предыдущей основной версии PostgreSQL необходимо перестроить хеш-индексы (Митхун Сай, Роберт Хаас, Амит Капила) Необходимость данного требования продиктована значительным усовершенствованием механизма хеш-индексов. Для облегчения задачи переиндексации pg_upgrade создаст вспомогательный скрипт.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Еще один аргумент против pg_upgrade}
^{Переименование каталога с журналом предзаписи из pg_xlog в pg_wal, а также переименование каталога с информацией о состоянии транзакций из pg_clog в pg_xact (Микаэль Пакье) Старые имена неоднократно вводили пользователей в заблуждение — пользователи думали, что эти каталоги содержат только несущественные файлы журналов, и вручную удаляли файлы журналов предзаписи или состояния транзакций, что приводило к необратимой потере данных. Эти переименования призваны предотвратить такие ошибки в будущем.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Замена в именах функций SQL, утилит и параметров всех упоминаний «xlog» на «wal» (Роберт Хаас) Например, имя pg_switch_xlog() поменялось на pg_switch_wal(), pg_receivexlog — на pg_receivewal, а --xlogdir — на --waldir. Это было сделано вместе с переименованием каталога pg_xlog для согласованности; и вообще термин «xlog» теперь нигде не может встретиться пользователю.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Замена в связанных с WAL функциях и представлениях location на lsn (Дэвид Роули) Ранее имело место несогласованное употребление обоих терминов.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Передача по умолчанию программой pg_basebackup данных WAL, необходимых для восстановления резервной копии (Магнус Хагандер) При этом в pg_basebackup подразумеваемое значение -X/--wal-method меняется на stream. Для воспроизведения старого поведения был добавлен вариант значения none. Параметр pg_basebackup -x был удалён (используйте вместо него -X fetch).}	^{Нарушение работы приложения}	^{Системный администратор}
^{Изменение записей логической репликации в pg_hba.conf (Питер Эйзентраут) В предыдущих версиях для соединения логической репликации требовалось указать replication в столбце базы данных. С этого выпуска логической репликации соответствует обычная запись с именем базы данных или ключевым словом, например, all. Для физической репликации по-прежнему используется ключевое слово replication. Так как встроенная логическая репликация появилась только в этом выпуске, это изменение может затронуть только пользователей сторонних средств логической репликации.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Все действия в pg_ctl по умолчанию должны ожидать завершения операции (Питер Эйзентраут) Ранее некоторые действия pg_ctl не ждали завершения и для ожидания требовалось использовать ключ -w.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Изменение значения по умолчанию серверного параметра log_directory с pg_log на log (Андреас Карлссон)}	^{Нарушение работы приложения}	^{Системный администратор}
^{Добавление параметра конфигурации ssl_dh_params_file для указания имени файла с нестандартными параметрами OpenSSL DH (Хейкки Линнакангас) Тем самым заменяется жёстко заданное и недокументированное имя файла dh1024.pem. Заметьте, что файл dh1024.pem по умолчанию больше не обрабатывается; вы должны задать этот параметр, если хотите использовать свои параметры DH.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Увеличение размера стандартных параметров DH, используемых для эфемерных DH-шифров OpenSSL, до 2048 бит (Хейкки Линнакангас) Размер предопределённых в коде параметров DH был увеличен с 1024 до 2048 бит, так что обмен ключами DH стал более устойчивым к подбору шифра. Однако некоторые старые реализации SSL, в частности некоторые ревизии Java Runtime Environment версии 6, не принимают параметры DH длиннее 1024 бит и, таким образом, не смогут подключиться через SSL. Если вам необходимо поддерживать такие старые клиенты, вы можете использовать нестандартные параметры DH размером 1024 бита вместо предопределённых параметров по умолчанию.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Ликвидация возможности хранения незашифрованных паролей на сервере (Хейкки Линнакангас) Серверный параметр password_encryption больше не поддерживает значения off и plain. Вариант UNENCRYPTED также теперь не поддерживается в командах CREATE/ALTER USER ... PASSWORD. Аналогично был удалён ключ --unencrypted команды createuser. Незашифрованные пароли, перенесённые из старых версий, в этой версии будут храниться в зашифрованном виде. Значением по умолчанию параметра password_encryption остаётся md5.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Добавление серверных параметров min_parallel_table_scan_size и min_parallel_index_scan_size для управления параллельными запросами (Амит Капила, Роберт Хаас) Они заменяют переменную min_parallel_relation_size, которая была слишком общей.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Желательно «загрепать» исходный код на предмет использования данного параметра при работе с сессией.}
^{Не заключённый в кавычки текст в shared_preload_libraries и связанных серверных параметрах не должен переводиться в нижний регистр (Куэль Чжо) Эти параметры на самом деле представляют собой списки имён файлов, но ранее они воспринимались как списки SQL-идентификаторов и обрабатывались по другим правилам.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Удаление серверного параметра sql_inheritance (Роберт Хаас) При выключенном значении этого параметра запросы, обращающиеся к родительским таблицам, перестают учитывать дочерние. Однако стандарт SQL требует, чтобы они учитывались, и это поведение было принято по умолчанию в PostgreSQL 7.1.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Ликвидация поддержки хранения даты/времени и интервалов в виде чисел с плавающей точкой (Том Лейн) Параметр configure --disable-integer-datetimes был удалён. Использование для таких значений чисел с плавающей точкой не давало значимых преимуществ и не было вариантом по умолчанию, начиная с PostgreSQL 8.3.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Касается разработчиков программных пакетов: rpm, deb, etc.}
^{Ликвидация поддержки сервером клиент-серверного протокола версии 1.0 (Том Лейн) Этот протокол не поддерживался клиентами со времён PostgreSQL 6.3.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Удаление модуля contrib/tsearch2 (Роберт Хаас) Этот модуль обеспечивал совместимость с версией полнотекстового поиска, которая поставлялась с серверами PostgreSQL до версии 8.3.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Ликвидация приложений командной строки createlang и droplang (Питер Эйзентраут) Они перешли в разряд устаревших в PostgreSQL 9.1. Вместо них можно непосредственно использовать команды CREATE EXTENSION и DROP EXTENSION.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Изменение реализации функций, возвращающих множества, в списке SELECT (Андрес Фройнд) Функции, возвращающие множества, теперь вычисляются до вычисления скалярных выражений в списке SELECT, практически так же, как если бы они были помещены в предложение LATERAL FROM. Это даёт более понятное поведение в случаях, когда присутствуют несколько таких функций. Если они возвращают разное количество строк, все результаты дополняются до наибольшего количества строк значениями NULL. Ранее результаты обрабатывались в цикле, пока все функции не завершались, и в результате получалось количество строк, равное наименьшему общему кратному периодов функций. Кроме того, функции, возвращающие множества, теперь нельзя использовать в конструкциях CASE и COALESCE.}	^{Падение производительности}	^{Разработчик}	^{В документации сказано про использование set-returning function (т.е. функций, которые могут возвращать таблицы) только в списке FROM. Маловероятно, что их кто-то использует внутри списка SELECT. Но если кто-то вдруг скопировал такой код из интернета и надеется на старую функциональность, то могут возникнуть проблемы. Поэтому лучше лишний раз проверить.}
^{Использование стандартного синтаксиса конструктора строки в UPDATE ... SET (список_столбцов) = конструктор_строки (Том Лейн) Теперь конструктор_строки может начинаться со слова ROW; ранее его надо было опускать. Если в списке_столбцов фигурирует имя только одного столбца, конструктор_строки должен использовать ключевое слово ROW, так как иначе он не будет корректным конструктором строки, а будет восприниматься как выражение в скобках. Также запись имя_таблицы.* в конструкторе_строки теперь разворачивается в набор столбцов, как и в других случаях использования конструктора_строки.}	^{Падение производительности}	^{Разработчик}	^{Перечисленное — обычные правила для row_constructor. Необычно лишь его применение в UPDATE таким вот образом. На практике подобных случаев не встречал, хотя в документации такой синтаксис появился еще в PostgreSQL 8.2. В 10-й версии, судя по всему, этот синтаксис привели к стандарту, который применяется в других версиях PostgreSQL. Как бы странно это ни выглядело, но вставить такой кусок кода возможно.}

Интересные фичи

Логическая репликация по схеме публикации/подписки

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

Декларативное секционирование таблиц

Новый декларативный синтаксис упростил партицирование таблиц.

Улучшение распараллеливания запросов

Изначально в 9.6 появилась поддержка параллельного выполнения больших запросов. Но она касалась только операций сканирования, join'ов и агрегаций.

В 10.0, в свою очередь, появилась возможность параллельного выполнения:

B-Tree index scan
Bitmap scan
Merge joins
Некоррелированных подзапросов

Более сильная защита паролей с использованием SCRAM-SHA-256

Может быть несовместим с какими-то нестандартными (не libpq) библиотеками подключения к PostgreSQL.

PostgreSQL 10.0 -> 11.0

Фича	Риск	Кому обратить внимание	Комментарий
^{Корректная обработка выражений с относительными путями в xmltable(), xpath() и других функциях, работающих с XML (Маркус Винанд) Согласно стандарту SQL, относительные пути нужно рассматривать от узла документа XML, а не от корневого узла, как раньше это делали данные функции.}	^{Нарушение работы приложения}	^{Разработчик}	^{Привели в соответствие со стандартом SQL. Актуально для тех, кто работает с XML. Если используются эти функции с относительными путями, их надо проверить.}
^{pg_dump теперь выгружает и свойства базы данных, а не только её содержимое (Харибабу Комми) Ранее такие атрибуты базы данных, как разрешения GRANT/REVOKE уровня базы данных и назначения переменных ALTER DATABASE SET, выгружались только утилитой pg_dumpall. Теперь при выполнении pg_dump --create и pg_restore --create в дополнение к объектам базы будут восстанавливаться и такие её свойства. При этом pg_dumpall -g будет выводить только атрибуты, связанные с ролями и табличными пространствами. Содержимое полного вывода pg_dumpall (без -g) не изменилось. Команды pg_dump и pg_restore без ключа --create теперь не выгружают/не восстанавливают комментарии на уровне базы и метки безопасности; эти атрибуты теперь считаются свойствами базы данных. При восстановлении вывода pg_dumpall теперь базы данных всегда должны восстанавливаться с исходными локалями и кодировками, и поэтому, если локаль или кодировка окажется неизвестной в целевой системе, произойдёт ошибка. Ранее команда CREATE DATABASE выдавалась без таких указаний, если локаль и кодировка базы данных не отличались от установленных по умолчанию в старом кластере. pg_dumpall --clean теперь позволяет восстановить исходные параметры локали и кодировки для баз данных postgres и template1, а не только для баз, создаваемых пользователями.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Касается только сисадминов. Несовместимость, т.к. поменялись принципы работы системных утилит. В то же время появилась возможность не апгрейдить все БД в кластере сразу. Начать с переноса ролей, далее с помощью pg_dump/pg_restore --create переносить БД по одной. Таким образом, можно избежать потери данных, которые прописаны в свойствах БД.}
^{Разрешение переиндексирования общих каталогов только для суперпользователей (Микаэль Пакье, Роберт Хаас) Ранее это также могли делать владельцы баз данных, но теперь эта операция считается выходящей за рамки их полномочий.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Удаление устаревших функций adminpack pg_file_read(), pg_file_length() и pg_logfile_rotate() (Стивен Фрост) Равнозначная функциональность теперь представлена в ядре сервера. Старые инсталляции adminpack продолжат использовать эти функции, пока не будут обновлены посредством ALTER EXTENSION ... UPDATE.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Ликвидация серверного параметра replacement_sort_tuples (Питер Гейган) Было решено, что сортировка с замещением в настоящее время не имеет практической пользы.}	^{Нарушение работы приложения}	^{Системный администратор}

Интересные фичи

Добавление оператора сопоставления префиксов text ^@ text и реализация его поддержки в SP-GiST (Ильдус Курбангалиев)

Он действует подобно конструкции переменная LIKE 'слово%' с индексом btree, но обрабатывается более эффективно.

Поиск по префиксу встречается довольно часто. Для этого добавили специальный оператор с поддержкой специальных индексов. И что самое интересное, в официальной документации про этот оператор не сказано ни слова. Вместо него упоминается функция starts_with — внутренняя функция, на которой основан этот оператор, но её использование не дает ускорения с помощью индекса.

Сведение выражения переменная = переменная к выражению переменная IS NOT NULL там, где они равнозначны (Том Лейн)

Благодаря этому улучшается оценка избирательности.

Как ни странно, встречали такую конструкцию на практике. Судя по всему, данный случай не редкий.

PostgreSQL 11.0 -> 12.0

Фича	Риск	Кому обратить внимание	Комментарий
^{Изменение поведения функции substring(), вызываемой в стиле SQL, на соответствующее стандарту, «жадное» (Том Лейн) В случаях, когда искомый шаблон может быть выбран в строке несколькими способами, начальному сегменту шаблона сопоставляется не наибольшая, а наименьшая подстрока; например, шаблон %#"aa*#"% теперь выбирает из входной строки не последнее, а первое вхождение ряда a.}	^{Нарушение работы приложения}	^{Разработчик}	^{Серьезное нарушение совместимости, которое может быть оправдано только тем, что привели функциональность в соответствие со стандартом SQL. Если кто-то использует функцию substring() с паттернами, то необходимо вдумчиво проверить, так как это может привести к труднопредсказуемым последствиям. Проблемы могут оказаться как на стороне БД, так и в запросах со стороны клиента.}
^{Перенос параметров recovery.conf в postgresql.conf (Масао Фудзии, Саймон Риггс, Абхиджит Менон-Сен, Сергей Корнилов) Файл recovery.conf более не используется, и сервер не запустится, если обнаружит его. Теперь для переключения сервера из режима ведущего используются файлы recovery.signal и standby.signal. Параметр trigger_file был переименован в promote_trigger_file, а параметр standby_mode удалён.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Недопущение конфликта множественных указаний recovery_target* (Питер Эйзентраут) А именно, допускается только одно из указаний recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time или recovery_target_xid. Ранее в конфигурации могли присутствовать несколько этих параметров, а действовало только последнее вхождение. Сейчас может задаваться только один, хотя если он задаётся неоднократно, действует так же только последнее указание.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Переход в процессе восстановления по умолчанию к последней линии времени (Питер Эйзентраут) То есть параметр recovery_target_timeline теперь имеет значение по умолчанию latest. Ранее подразумевалось значение current.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Переименование утилиты командной строки pg_verify_checksums в pg_checksums (Микаэль Пакье)}	^{Нарушение работы приложения}	^{Системный администратор}
^{Добавление в pg_restore требования ключа -f — для получения содержимого дампа через стандартное устройство вывода (Эйлер Тавейра) Ранее дамп выводился в стандартное устройство вывода и тогда, когда назначение не указывалось, но это было признано нежелательным поведением.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Недопущение неоднозначных сокращений в команде \pset format утилиты psql (Даниэль Верите) Ранее, например, при вводе команды \pset format a выбирался вариант aligned; однако возможен и вариант asciidoc, поэтому теперь не будет выбираться никакой.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Изменения в формате \pset внутри команды psql. Теоретически, это может коснуться системных администраторов или тех, кто работает с БД через psql и использует \pset.}
^{В новых индексах btree максимальный размер записи индекса сокращён на 8 байт с целью усовершенствования обработки повторяющихся элементов (Питер Гейган) Вследствие этого при выполнении REINDEX с индексом, полученным в результате обновления предыдущей версии с применением pg_upgrade, может возникнуть ошибка.}	^{Нарушение работы приложения}	^{Системный администратор}	^{Касается только системных администраторов. Важное замечание, которое обязательно должно быть учтено. Подробнее мы написали в начале, когда рассуждали о разных способах апгрейда. Еще один аргумент не в пользу pg_upgrade.}
^{Удаление возможности отключения динамической общей памяти (Кётаро Хоригути) Таким образом, параметр dynamic_shared_memory_type теперь не может принимать значение none.}	^{Нарушение работы приложения}	^{Системный администратор}
^{Автоматическое встраивание в запрос общих табличных выражений (CTE), с возможностью переопределения этого поведения}	^{Падение производительности}	^{Разработчик}	^{В официальной документации эта фича не помечена как несовместимая. Но, как мудро заметил Олег Бартунов, тут возможны проблемы при портировании, только не функциональные, а связанные с производительностью. В 12-й версии обычные CTE из старых версий будут больше подвержены оптимизации планировщика. Теоретически это только в плюс, и производительность, скорее всего, вырастет. Но если планировщик не отрабатывает должным образом, это сможет привести к драматическому падению производительности. Для контроля и быстрого реагирования на проблемы производительности желательно, чтобы pg_stat_statments был установлен заранее на все БД. Удобнее всего это сделать, добавив его в template1.}

Интересная фича

Реализация более компактного хранения многоколоночных индексов btree (Питер Гейган, Хейкки Линнакангас)

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

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

Еще один аргумент не в пользу pg_upgrade.

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

P.S.
Спасибо Самойлову Олегу(splarv) за помощь в подготовке статьи.

Источник: https://habr.com/ru/company/domclick/blog/511224/

Вернуться к списку

Интересные статьи

Microsoft планирует крупное обновление пользовательского интерфейса Windows 10

Microsoft готовит крупное обновление ОС для Windows 10 в 2021 году, которое, по информации источников, принесет с собой значительное обновление дизайна пользовательского ...

Персонализации в интернет-магазине 1С-Битрикс

Принято считать, что персонализация в интернете это магия, которая создается сотнями серверов на основе БигДата и сложного семантического анализа контента.

Отгрузки в новом ядре D7 1С-Битрикс

Если честно, к Д7 у меня несколько неоднозначное отношение. В некоторых местах я попискиваю от восторга, а в некоторых хочется топать ногами и ругаться неприличными словами.

Сайт на бесплатной CMS или купить готовое решение на 1С-Битрикс?

Периодически мне в разных вариантах задают вопрос, который «в среднем» звучит так: «что лучше: заказать интернет-магазин на бесплатной CMS или купить готовое решение на 1С-Битрикс и сделать магазин на...

Мегафон провел техническое обновление… названия сети

Абоненты МегаФона испытали на себе изменение названия сети, к слову «MegaFon» добавилось «Fastest».