Postgresql 10 что нового – Вышел PostgreSQL 10 / Habr

После обновления с помощью pg_upgrade с любой предыдущей основной версии PostgreSQL необходимо перестроить хеш-индексы (Митхун Сай, Роберт Хаас, Амит Капила)

Необходимость данного требования продиктована значительным усовершенствованием механизма хеш-индексов. Для облегчения задачи переиндексации 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 (Дэвид Роули)

Ранее имело место несогласованное употребление обоих терминов.

Изменение реализации функций, возвращающих множества, в списке SELECT (Андрес Фройнд)

Функции, возвращающие множества, теперь вычисляются до вычисления скалярных выражений в списке SELECT, практически так же, как если бы они были помещены в предложение LATERAL FROM. Это даёт более понятное поведение в случаях, когда присутствуют несколько таких функций. Если они возвращают разное количество строк, все результаты дополняются до наибольшего количества строк значениями NULL. Ранее результаты обрабатывались в цикле, пока все функции не завершались, и в результате получалось количество строк, равное наименьшему общему кратному периодов функций. Кроме того, функции, возвращающие множества, теперь нельзя использовать в конструкциях CASE и COALESCE. За дополнительными сведениями обратитесь к Подразделу 37.4.8.

Использование стандартного синтаксиса конструктора строки в UPDATE ... SET (список_столбцов) = конструктор_строки (Том Лейн)

Теперь конструктор_строки может начинаться со слова ROW; ранее его надо было опускать. Если в списке_столбцов фигурирует имя только одного столбца, конструктор_строки должен использовать ключевое слово ROW, так как иначе он не будет корректным конструктором строки, а будет восприниматься как выражение в скобках. Также запись имя_таблицы.* в конструкторе_строки теперь разворачивается в набор столбцов, как и в других случаях использования конструктора_строки.

Когда ALTER TABLE ... ADD PRIMARY KEY помечает столбцы как NOT NULL, это изменение теперь распространяется также на дочерние таблицы в иерархии наследования (Микаэль Пакье)

Предотвращение срабатывания триггеров уровня оператора более одного раза для одного оператора (Том Лейн)

В случаях, когда пишущие CTE изменяли одну таблицу, изменяемую внешним оператором либо другими пишущими CTE, триггеры BEFORE STATEMENT и AFTER STATEMENT вызывались неоднократно. Также, если в таблице были определены триггеры уровня оператора, в результате действий для обеспечения целостности внешнего ключа (например, ON DELETE CASCADE), они могли вызываться несколько раз для одного внешнего SQL-оператора. Это поведение противоречит стандарту SQL и было исправлено.

Перемещение полей метаданных последовательностей в новый системный каталог pg_sequence (Питер Эйзентраут)

Отношение последовательности содержит теперь только поля, которые могут быть изменены функцией nextval(), то есть last_value, log_cnt и is_called. Другие свойства последовательности, такие как начальное значение и шаг увеличения, сохраняются в соответствующей строке в каталоге pg_sequence. Действие ALTER SEQUENCE теперь полностью транзакционное и, как следствие, блокирует последовательность до фиксации транзакции. Функции nextval() и setval() остаются нетранзакционными.

Основная несовместимость, привнесённая этим изменением, состоит в том, что из отношения последовательности теперь можно прочитать только три поля, перечисленные выше. Чтобы получить другие свойства последовательности, приложения должны обратиться к pg_sequence. Также для этого можно использовать новое системное представление pg_sequences; оно выдаёт столбцы с именами, более подходящими для существующего кода.

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

Переработан и вывод команды psql \d для последовательностей.

Передача по умолчанию программой 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 (Хейкки Линнакангас)

Тем самым заменяется жёстко заданное и недокументированное имя файла dh2024.pem. Заметьте, что файл dh2024.pem по умолчанию больше не обрабатывается; вы должны задать этот параметр, если хотите использовать свои параметры DH.

Увеличение размера стандартных параметров DH, используемых для эфемерных DH-шифров OpenSSL, до 2048 бит (Хейкки Линнакангас)

Размер предопределённых в коде параметров DH был увеличен с 1024 до 2048 бит, так что обмен ключами DH стал более устойчивым к подбору шифра. Однако некоторые старые реализации SSL, в частности некоторые ревизии Java Runtime Environment версии 6, не принимают параметры DH длиннее 1024 бит и, таким образом, не смогут подключиться через SSL. Если вам необходимо поддерживать такие старые клиенты, вы можете использовать нестандартные параметры DH размером 1024 бита вместо предопределённых параметров по умолчанию. См. ssl_dh_params_file.

Ликвидация возможности хранения незашифрованных паролей на сервере (Хейкки Линнакангас)

Серверный параметр 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.

Реализация возможности передавать многомерные массивы в функции на PL/Python и возвращать вложенные списки Python (Алексей Грищенко, Дэйв Крамер, Хейкки Линнакангас)

Это изменение потребовало нарушить обратную совместимость в части обработки массивов составных типов в PL/Python. Раньше можно было вернуть массив составных типов как [[col1, col2], [col1, col2]]; но теперь это будет интерпретироваться как двухмерный массив. Составные типы в массивах для однозначности должны возвращаться теперь в виде кортежей Python, а не в виде списков. То есть предыдущую запись нужно заменить на [(col1, col2), (col1, col2)].

Удаление механизма автозагрузки «модулей» PL/Tcl (Том Лейн)

На замену этой функциональности пришли новые серверные параметры pltcl.start_proc и pltclu.start_proc, которые проще в использовании и дают возможности, подобные имеющимся в других языках программирования.

Ликвидация поддержки выгрузки данных с серверов до 8.0 утилитами pg_dump/pg_dumpall (Том Лейн)

Пользователям, которым нужно выгрузить данные с серверов до 8.0, остаётся использовать dump из PostgreSQL версии 9.6 или старее. Выгруженные этими версиями данные должны успешно загружаться на новых серверах.

Ликвидация поддержки хранения даты/времени и интервалов в виде чисел с плавающей точкой (Том Лейн)

Параметр configure --disable-integer-datetimes был удалён. Использование для таких значений чисел с плавающей точкой не давало значимых преимуществ и не было вариантом по умолчанию, начиная с PostgreSQL 8.3.

Ликвидация поддержки сервером клиент-серверного протокола версии 1.0 (Том Лейн)

Этот протокол не поддерживался клиентами со времён PostgreSQL 6.3.

Удаление модуля contrib/tsearch3 (Роберт Хаас)

Этот модуль обеспечивал совместимость с версией полнотекстового поиска, которая поставлялась с серверами PostgreSQL до версии 8.3.

Ликвидация приложений командной строки createlang и droplang (Питер Эйзентраут)

Они перешли в разряд устаревших в PostgreSQL 9.1. Вместо них можно непосредственно использовать команды CREATE EXTENSION и DROP EXTENSION.

Ликвидация поддержки вызовов функций версии 0 (Андрес Фройнд)

Расширения, предоставляющие функции, реализованные на C, теперь должны использовать соглашение о вызовах версии 1. Версия 0 считалась устаревшей с 2001 года.

Переместить старый кластер (необязательно)

Если ваш каталог инсталляции привязан к версии, например, /opt/PostgreSQL/10, перемещать его не требуется. Все графические инсталляторы выбирают при установке каталоги, привязанные к версии.

Если ваш каталог инсталляции не привязан к версии, например /usr/local/pgsql, необходимо переместить каталог текущей инсталляции PostgreSQL, чтобы он не конфликтовал с новой инсталляцией PostgreSQL. Когда текущий сервер PostgreSQL отключён, каталог этой инсталляции PostgreSQL можно безопасно переместить; если старый каталог

mv /usr/local/pgsql /usr/local/pgsql.old

Собрать новую версию при установке из исходного кода

Соберите из исходного кода новую версию PostgreSQL с флагами configure, совместимыми с флагами старого кластера. Программа pg_upgrade проверит результаты pg_controldata, чтобы убедиться, что все параметры совместимы, прежде чем начинать обновление.

Установить новые исполняемые файлы PostgreSQL

Установите новые исполняемые файлы сервера и вспомогательные файлы. Программа pg_upgrade включена в инсталляцию по умолчанию.

При установке из исходного кода, если вы хотите разместить сервер в нестандартном каталоге, воспользуйтесь переменной prefix:

make prefix=/usr/local/pgsql.new install

Инициализировать новый кластер PostgreSQL

Инициализируйте новый кластер, используя initdb. При этом так же необходимо указать флаги initdb, совместимые с флагами в старом кластере. Многие готовые инсталляторы выполняют это действие автоматически. Запускать новый кластер не требуется.

Установить дополнительные разделяемые объектные файлы

Установите в новый кластер все нестандартные разделяемые объектные файлы (или DLL), которые использовались в старом кластере, например, pgcrypto.so, где бы они ни находились — в contrib или в другом месте. Устанавливать определения схемы (например, CREATE EXTENSION pgcrypto) не требуется, так как они будут перенесены из старого кластера. Кроме того, в новый кластер нужно скопировать и все нестандартные файлы поддержки полнотекстового поиска (словари, тезаурусы, списки синонимов и стоп-слов).

Настроить аутентификацию

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

Остановить оба сервера

Убедитесь в том, что оба сервера баз данных остановлены. Для этого в Unix можно выполнить:

pg_ctl -D /opt/PostgreSQL/9.6 stop
pg_ctl -D /opt/PostgreSQL/10 stop

А в Windows, с соответствующими именами служб:

NET STOP postgresql-9.6
NET STOP postgresql-10

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

Подготовиться к обновлению ведомых серверов

Если вы производите обновление ведомых серверов (как описано в разделе Шаг 10), удостоверьтесь, что эти серверы находятся в актуальном состоянии, запустив pg_controldata в старых ведущем и ведомых кластерах. Убедитесь в том, что «Положение последней контрольной точки» во всех кластерах одинаковое. (Несовпадение будет иметь место, если старые ведомые серверы будут отключены раньше, чем старый ведущий, или если старые сервера продолжают работать.) Также смените

Запустить pg_upgrade

Всегда запускайте программу pg_upgrade от нового сервера, а не от старого. pg_upgrade требует указания каталогов данных старого и нового кластера, а также каталогов исполняемых файлов (bin). Вы можете также определить имя пользователя и номера портов, и нужно ли копировать файлы данных (по умолчанию) или создавать ссылки на них.

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

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

В Windows вы должны войти в систему с административными полномочиями, затем запустить командную строку от имени пользователя postgres, задать подходящий путь:

RUNAS /USER:postgres "CMD.EXE"
SET PATH=%PATH%;C:\Program Files\PostgreSQL\10\bin;

Наконец, запустить pg_upgrade с путями каталогов в кавычках, например, так:

pg_upgrade.exe
        --old-datadir "C:/Program Files/PostgreSQL/9.6/data"
        --new-datadir "C:/Program Files/PostgreSQL/10/data"
        --old-bindir "C:/Program Files/PostgreSQL/9.6/bin"
        --new-bindir "C:/Program Files/PostgreSQL/10/bin"

При запуске pg_upgrade проверит два кластера на совместимость и, если всё в порядке, выполнит обновление. Также возможно запустить pg_upgrade --check, чтобы ограничиться только проверками (при этом старый сервер может продолжать работать). Команда pg_upgrade --check также сообщит, какие коррективы вам нужно будет внести вручную после обновления. Если вы планируете использовать режим ссылок на данные, укажите вместе с --check параметр --link, чтобы были проведены специальные проверки для этого режима. Программе pg_upgrade требуются права на запись в текущий каталог.

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

Если при восстановлении схемы базы данных происходит ошибка, pg_upgrade завершает свою работу и вы должны вернуться к старому кластеру, как описывается ниже в Шаг 16. Чтобы попробовать pg_upgrade ещё раз, вы должны внести коррективы в старом кластере, чтобы pg_upgrade могла успешно восстановить схему. Если проблема возникла в модуле contrib, может потребоваться удалить этот модуль contrib в старом кластере, а затем установить его в новом после обновления (предполагается, что этот модуль не хранит пользовательские данные).

Обновить ведомые серверы с потоковой репликацией и трансляцией журнала

Если вы используете режим ссылок и у вас реализована потоковая репликация (см. Подраздел 26.2.5) или трансляция журнала (см. Раздел 26.2) для ведомых серверов, вы можете быстро обновить эти серверы следующим образом. Вам не нужно будет запускать на них pg_upgrade, вместо этого вы выполните rsync на ведущем. Не запускайте никакие серверы на этом этапе.

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

1. Установите новые исполняемые файлы PostgreSQL на ведомых серверах

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

2. Убедитесь в том, что новые каталоги данных на ведомых серверах

   не существуют

   Новые каталоги данных ведомых серверов должны отсутствовать либо быть пустыми. Если запускалась программа initdb, удалите новые каталоги данных на ведомых.

3. Установить дополнительные разделяемые объектные файлы

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

4. Остановите ведомые серверы

   Если ведомые серверы продолжают работу, остановите их, следуя приведённым выше инструкциям.

5. Сохраните файлы конфигурации

   Сохраните все нужные вам файлы конфигурации из старых каталогов конфигурации ведомых серверов, в частности postgresql.conf и recovery.conf, так как они будут перезаписаны или удалены на следующем этапе.

6. Запустите rsync

   Когда используется режим ссылок, ведомые серверы можно быстро обновить, применив rsync. Для этого в каталоге, внутри которого находятся каталоги старого и нового кластера, для каждого ведомого сервера выполните на ведущем:

   rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir

   Здесь каталоги old_cluster и new_cluster задаются относительно текущего каталога на ведущем, а remote_dir находится над каталогами старого и нового кластера на ведомом. Структура подкаталогов в заданных каталогах на ведущем и ведомых серверах должна быть одинаковой. Обратитесь к странице руководства rsync, где подробно описано, как указать удалённый каталог, например так:

   rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/9.5 \
         /opt/PostgreSQL/9.6 standby.example.com:/opt/PostgreSQL

   Проверить, что будет делать команда, можно, воспользовавшись параметром rsync --dry-run. Выполнить rsync на ведущем необходимо как минимум с одним ведомым, но затем, пока обновлённый ведомый остаётся остановленным, можно запускать rsync на нём для обновления других ведомых.

   В ходе этой операции записываются ссылки, созданные режимом ссылок pg_upgrade, связывающие файлы нового и старого кластера на ведущем сервере. Затем в старом кластере ведомого находятся соответствующие файлы и в новом кластере ведомого создаются ссылки на них. Файлы, не связанные ссылками на ведущем, копируются с него на ведомый. (Обычно их объём невелик.) Это позволяет произвести обновление ведомого быстро. К сожалению, при этом rsync будет напрасно копировать файлы, связанные с временными и нежурналируемыми таблицами, так как они обычно не будут существовать на ведомых серверах.

   Если у вас есть табличные пространства, вам потребуется выполнить подобную команду rsync для каталогов всех табличных пространств, например:

   rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_9.5_201510051 \
         /vol1/pg_tblsp/PG_9.6_201608131 standby.example.com:/vol1/pg_tblsp

   Если вы вынесли pg_wal за пределы каталогов данных, нужно будет запустить rsync и для этих каталогов.

7. Настройте ведомые серверы с потоковой репликацией и трансляцией журнала

   Настройте серверы для трансляции журнала. (Запускать pg_start_backup() и pg_stop_backup() или делать копию файловой системы не нужно, так как ведомые серверы остаются синхронизированными с ведущим.)

Восстановить pg_hba.conf

Если вы изменяли pg_hba.conf, восстановите его исходное состояние. Также может потребоваться скорректировать другие файлы конфигурации в новом кластере, чтобы они соответствовали старому, например postgresql.conf.

Запустить новый сервер