pg_upgrade

примечание

Эта страница переведена при помощи нейросети GigaChat.

warning

Изменено поведение оригинальной утилиты. Изменения описаны в рамках подраздела «Доработки Pangolin».

pg_upgrade — обновляет экземпляр сервера PostgreSQL.

Синтаксис

pg_upgrade -b oldbindir [-B newbindir] -d oldconfigdir -D newconfigdir [option ...]

Описание

pg_upgrade (ранее известная как pg_migrator) позволяет обновить данные в файлах PostgreSQL до более новой версии, избегая необходимости в дампе и восстановлении данных, что обычно требуется при обновлении между основными версиями (например, с 9.5.8 до 9.6.4 или с 10.7 до 11.2). Для незначительных обновлений версий (например, с 9.6.2 до 9.6.3 или с 10.1 до 10.2) эта операция не требуется.

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

Утилита проверяет двоичную совместимость старого и нового кластеров, включая проверку совместимости настроек компиляции, таких как архитектура (32-бит или 64-бит). Важно, чтобы все внешние модули также были совместимы, однако это не может быть проверено самим pg_upgrade.

pg_upgrade поддерживает обновления с версии 9.2.X и выше до текущей основной версии PostgreSQL, включая моментальные снимки и бета-версии.

warning

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

Параметры

Для утилиты pg_upgrade существуют следующие параметры командной строки:

-b bindir
--old-bindir=bindir

Указывает каталог старых исполняемых файлов PostgreSQL. Переменная окружения: PGBINOLD.

-B bindir
--new-bindir=bindir

Указывает каталог новых исполняемых файлов PostgreSQL. По умолчанию это каталог, в котором находится pg_upgrade. Переменная окружения: PGBINNEW.

-c
--check

Проверяет кластеры без внесения изменений в данные.

-d configdir
--old-datadir=configdir

Указывает каталог конфигурации старого кластера баз данных. Переменная окружения: PGDATAOLD.

-D configdir
--new-datadir=configdir

Указывает каталог конфигурации нового кластера баз данных. Переменная окружения: PGDATANEW.

-j n_jobs
--jobs=n_jobs

Указывает количество процессов или потоков, которые могут работать одновременно.

-k
--link

Использует жесткие ссылки вместо копирования файлов в новый кластер.

-N
--no-sync

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

Параметр используется при тестировании и не предназначен для производственной среды.

-o options
--old-options options

Указывает параметры, которые должны быть переданы старому процессу postgres. Несколько параметров складываются вместе.

-O options
--new-options options

Указывает параметры, которые должны быть переданы новому процессу postgres. Несколько параметров складываются вместе.

-p port
--old-port=port

Указывает номер порта старого кластера. Переменная окружения: PGPORTOLD.

-P port
--new-port=port

Указывает номер порта нового кластера. Переменная окружения: PGPORTNEW.

-r
--retain

Сохраняет файлы SQL и журналов, даже если обновление завершилось успешно.

-s dir
--socketdir=dir

Указывает каталог для сокетов postmaster во время обновления. По умолчанию используется текущий рабочий каталог. Переменная окружения: PGSOCKETDIR.

-U username
--username=username

Указывает имя пользователя, выполняющего установку кластера. Переменная окружения: PGUSER.

-v
--verbose

Включает подробный журнал выполнения.

-V
--version

Выводит версию pg_upgrade и завершается.

--clone

Использует эффективное клонирование файлов (также известное как «reflinks» в некоторых системах) вместо их копирования в новый кластер. Это может значительно ускорить процесс копирования, оставляя старый кластер нетронутым.

Клонирование файлов поддерживается только в некоторых операционных системах и файловых системах. В настоящее время это поддерживается в Linux с Btrfs или XFS (в файловых системах, созданных с поддержкой reflink), macOS с APFS. Если он выбран, но не поддерживается, выполнение pg_upgrade завершится ошибкой.

-?
--help

Показывает справку о параметрах командной строки утилиты pg_upgrade и завершается.

Использование

Ниже приведен порядок действий для обновления кластера PostgreSQL с помощью утилиты pg_upgrade:

Шаги для выполнения обновления с помощью pg_upgrade:

1. Переименование старого каталога установки (опционально).

   При использовании каталога установки, привязанного к версии (например, /opt/PostgreSQL/15) перемещать его не требуется. Все графические инсталляторы выбирают при установке каталоги, привязанные к версии.

   Если же каталог установки не привязан к версии (например, /usr/local/pgsql), необходимо переместить текущий каталог установки PostgreSQL, чтобы он не мешал новой установке PostgreSQL.

   Остановите сервер текущей PostgreSQL, затем переместите или, в случае с /usr/local/pgsql, переименуйте каталог установки, чтобы новая инсталляция могла использовать тот же путь:

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

2. Сборка новой версии из исходников.

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

3. Установка двоичных файлов новой версии.

   Установите новые бинарные файлы сервера и необходимые библиотеки (pg_upgrade включен в установку по умолчанию).

   Для установки в пользовательскую директорию используйте параметр prefix:

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

4. Инициализация нового кластера.

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

5. Установка общих расширений.

   Многие расширения и пользовательские модули, включая те, что идут из contrib или других источников, используют общие объектные файлы (или DLL-файлы), например, pgcrypto.so.

   Если старый кластер использовал такие файлы, установите их версии, соответствующие новому серверу, в новый кластер, обычно с помощью команд операционной системы. Не выполняйте повторно команды для установки схем, такие как CREATE EXTENSION pgcrypto, так как они уже присутствуют в старом кластере. В случае наличия обновлений для расширений, pg_upgrade уведомит об этом и создаст скрипт для их последующего обновления.

6. Копия пользовательских файлов полнотекстового поиска.

   Скопируйте все пользовательские файлы полнотекстового поиска (например, словари, синонимы и стоп-слова) из старого кластера в новый.

7. Настройка авторизации.

   pg_upgrade будет подключаться к старым и новым серверам несколько раз, поэтому настройте аутентификацию на peer в pg_hba.conf или используйте файл ~/.pgpass.

8. Остановка обоих серверов.

   Остановите оба сервера базы данных перед запуском обновления. Для этого в Unix выполните:

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

   или в Windows, используя соответствующие имена служб:

   NET STOP postgresql-9.6
   NET STOP postgresql-15

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

9. Синхронизация реплик.

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

   Для этого запустите pg_controldata как для основного, так и для резервных кластеров, и проверьте, что значения «положение последней контрольной точки» совпадают. Кроме того, убедитесь, что в конфигурационном файле postgresql.conf нового основного кластера параметр wal_level не установлен в значение minimal.

10. Запуск pg_upgrade.

    Рекомендуется запускать утилиту pg_upgrade от нового сервера PostgreSQL, а не от старого. При запуске необходимо указать пути к каталогам данных и исполняемым файлам (bin) как старого, так и нового кластеров. Также можно задать имя пользователя, порт и выбрать метод переноса данных — копирование, создание ссылок или клонирование.

    Если выбран режим ссылок, файлы данных не копируются, что позволяет ускорить процесс обновления и сократить использование дискового пространства. Однако в этом случае доступ к старому кластеру будет невозможен после запуска нового. Для использования режима ссылок оба каталога данных должны находиться в одной и той же файловой системе (исключение составляют табличные пространства и pg_wal, которые могут быть на других файловых системах).

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

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

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

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

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

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

    После запуска pg_upgrade выполняется проверка совместимости между старым и новым кластерами, а затем — само обновление. При необходимости можно предварительно выполнить только проверку, используя команду pg_upgrade --check. Эта команда работает даже при активном старом сервере и укажет, какие изменения потребуется внести вручную после завершения обновления. Если планируется использовать режим ссылок (--link) или клонирования (--clone), рекомендуется комбинировать его с --check, чтобы провести соответствующие дополнительные проверки. Утилита pg_upgrade должна запускаться из каталога, в котором есть права на запись.

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

    Если в ходе восстановления схемы возникнет ошибка, pg_upgrade остановится, и потребуется вернуться к использованию старого кластера, как описано в шаге 17. Повторный запуск возможен только после устранения проблемы в старом кластере, которая мешает корректному восстановлению схемы. Если сбой вызван модулем из набора contrib, возможно, его нужно будет удалить из старого кластера и переустановить в новом после обновления — при условии, что он не содержит пользовательских данных.

11. (ru-ru.PGUPGRADE-STEP-REPLICAS)= Обновление резервных серверов.

    Если при обновлении был выбран режим ссылок и используются резервные серверы с потоковой или логической репликацией. Смотрите раздел «Потоковая репликация» и раздел «Резервные серверы с передачей журналов»), для их быстрой актуализации можно воспользоваться описанными ниже действиями. В этом случае запуск pg_upgrade на резервных серверах не требуется — вместо этого на основном сервере выполните rsync. При этом запускать какие-либо серверы пока не нужно.

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

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

    1. Установка новых двоичных файлов PostgreSQL на резервные серверы.

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

    2. Проверка каталогов данных резервных серверов.

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

    3. Установка общих объектных файлов расширений.

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

    4. Остановка резервных серверов.

       Если резервные серверы продолжают работать, остановите их перед выполнением дальнейших действий.

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

       Сохраните все нужные файлы конфигурации из старых каталогов конфигурации ведомых серверов, в частности postgresql.conf, postgresql.auto.conf, pg_hba.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_backup_start() и pg_backup_stop() или выполнять копирование файлов вручную, так как резервные серверы уже синхронизированы с основным. Слоты репликации при этом не копируются и должны быть созданы заново.

12. Восстановление pg_hba.conf

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

13. Запуск нового кластера

    Новый сервер теперь можно безопасно запустить, а затем любые rsync резервные серверы.

14. Действия после обновления

    Если после выполнения pg_upgrade требуется дополнительная обработка, инструмент отобразит соответствующие предупреждения. Также он создаст сценарии SQL, которые необходимо выполнить вручную. Каждый из таких файлов подключается к базе данных, для которой требуется доработка. Каждый сценарий должен запускаться с использованием:

    psql --username=postgres --file=script.sql postgres

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

    Осторожно

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

15. Статистика

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

16. Удаление старого кластера

    После того как работоспособность нового кластера подтверждена, старый кластер можно удалить, выполнив сценарий, предложенный pg_upgrade по завершении. Автоматическое удаление невозможно, если в старом кластере использовались пользовательские табличные пространства. Также можно вручную удалить старые каталоги установки PostgreSQL (например, bin, share).

17. (ru-ru.PGUPGRADE-STEP-REVERT)= Возврат к старому кластеру

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

    • Использовалась только проверка (--check), старый кластер не был затронут и может быть запущен заново.

    • Режим ссылок (--link) не применялся, данные старого кластера остались неизменными, и он может быть повторно запущен.

    • Использовался режим ссылок (--link), возможны следующие ситуации, если:

      • pg_upgrade был прерван до создания ссылок, старый кластер остается неизменным и может быть снова запущен.
      • Новый кластер не запускался, старый изменен только частично — к файлу $PGDATA/global/pg_control добавлен суффикс .old. Для восстановления достаточно удалить этот суффикс, после чего кластер снова станет работоспособным.
      • Новый кластер запускался, он мог изменить общие файлы. В этом случае использование старого кластера небезопасно, и для восстановления потребуется резервная копия.

Примечания

pg_upgrade во время работы создает ряд вспомогательных файлов, таких как дампы схем, которые хранятся в каталоге pg_upgrade_output.d внутри нового кластера. Для каждого запуска создается отдельный подкаталог с именем, включающим временную метку в формате ISO 8601 (%Y%m%dT%H%M%S), где хранятся все сгенерированные файлы. Если pg_upgrade завершается успешно, каталог pg_upgrade_output.d и его содержимое удаляются автоматически. В случае сбоя эти файлы могут оказаться полезными для отладки.

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

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

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

pg_upgrade не поддерживает обновление баз данных, содержащих столбцы, использующие системные типы данных семейства reg*, ссылающиеся на OID:

• regcollation
• regconfig
• regdictionary
• regnamespace
• regoper
• regoperator
• regproc
• regprocedure

Обновление возможно для типов regclass, regrole и regtype.

Если планируется использовать режим ссылок (--link), но необходимо избежать изменений в старом кластере после запуска нового, следует применить режим клонирования (--clone). При отсутствии поддержки клонирования в файловой системе можно вручную создать копию старого кластера и выполнить обновление этой копии в режиме ссылок.

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

При необходимости можно исключить отдельные файлы, такие как postmaster.pid, как указано в разделе «Создание резервной копии базы данных с использованием низкоуровневого API», чтобы избежать нежелательного поведения.

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

Смотрите также

initdb, pg_ctl, pg_dump, postgres

Доработки Pangolin

Для обеспечения корректной работы обновления стендов, где используются расширения с предопределенными SRID, а также типы данных geometry и geography в виде массивов и объекты физического хранения на их основе, алгоритм работы pg_upgrade был разделен на 2 фазы. В общем случае в первую фазу обновления попадают только объекты, относящиеся к расширениям, определенным по умолчанию или заданным с помощью параметра --two-phases-extensions. Список расширений заданных по умолчанию приведен ниже:

fuzzystrmatch, postgis, postgis_raster, postgis_sfcgal, postgis_topology, postgis_tiger_geocoder, address_standardizer, address_standardizer_data_us, pgrouting

Во вторую фазу попадают все остальные объекты, не попавшие в первую фазу.

Более подробно алгоритм работы утилиты выглядит так:

1. Создание дампов всех баз данных обновляемого сервера в режиме --schema-only.
2. Для базы template1 применяется двухфазное обновление:
   1. Восстановление на новом сервере ТОЛЬКО схем объектов расширений.
   2. Копирование файлов данных, относящихся ТОЛЬКО к объектам расширений.
   3. Восстановление на новом сервере схем БЕЗ объектов расширений.
   4. Копирование файлов данных, НЕ относящихся к объектам расширений.
3. Для всех остальных баз данных (исключая template1) применяется двухфазное обновление:
   1. Восстановление на новом сервере ТОЛЬКО схем объектов расширений.
   2. Копирование файлов данных, относящихся ТОЛЬКО к объектам расширений.
   3. Восстановление на новом сервере схем БЕЗ объектов расширений.
   4. Линковка файлов данных, НЕ относящихся к объектам расширений.

Обработка базы данных template1 явно делается перед обработкой всех остальных баз данных, как это и было сделано в ванильной версии, так как из template1 создаются все остальные базы.

На этапах 2.2, 2.4, 3.2 производится принудительное копирование данных для обеспечения отказоустойчивости и возможности восстановления работы обновляемого сервера без каких-либо дополнительных манипуляций в случае, если работа pg_upgrade будет прервана по какой-либо причине вплоть до этапа 3.4. До этого момента никакие данные обновляемого сервера еще не затронуты. После выполнения этапа 3.4 и запуска нового сервера данные обновляемого сервера уже необходимо восстанавливать из резервной копии.

Чтобы отделить отношения объектов расширений от остальных объектов базы данных при линковке/копировании, используется запрос вида:

SQL запрос выводящий список OID отношений объектов расширений

WITH cnst(exts,objs) AS (
VALUES ('{fuzzystrmatch,postgis,postgis_raster,postgis_sfcgal,postgis_topology,postgis_tiger_geocoder,address_standardizer,address_standardizer_data_us,pgrouting}'::name[]
       ,'{extension,schema,default acl,language,type,array type,table,default value,sequence,operator,operator class,operator family,cast,aggregate,function,procedure,view,materialized view,rule}'::name[])
), objs(classid,objid,objsubid,extname,"type","schema","name","identity") AS (
SELECT
	pgd.classid,
	pgd.objid,
	pgd.objsubid,
	pge.extname,
    (pg_catalog.pg_identify_object(pgd.classid,pgd.objid,pgd.objsubid)).*
  FROM pg_catalog.pg_depend pgd
  JOIN pg_catalog.pg_extension pge ON pge.oid=pgd.refobjid
  JOIN cnst ON true
  WHERE
    pge.extname= ANY(exts)
    AND pgd.deptype IN ('e','x')
    AND pgd.refclassid='pg_catalog.pg_extension'::pg_catalog.regclass
), ext_objs(classid,objid,objsubid,extname,"type","schema","name","identity") AS (
SELECT DISTINCT
	'pg_catalog.pg_class'::regclass::oid,
	pgo.oid,
	0::oid,
	objs.extname,
	(pg_catalog.pg_identify_object('pg_catalog.pg_class'::regclass,pgo.oid,0::int4)).*
FROM pg_catalog.pg_class pgc
	JOIN objs ON objs.classid='pg_catalog.pg_class'::regclass::oid AND objs.objid = pgc.oid
	JOIN pg_catalog.pg_class pgo ON pgc.oid=pgo.oid
		OR pgo.oid=pgc.reltoastrelid
		OR pgo.oid IN (SELECT indexrelid FROM pg_catalog.pg_index WHERE indrelid=pgc.oid)
		OR pgo.oid IN (SELECT indexrelid FROM pg_catalog.pg_index WHERE indrelid=pgc.reltoastrelid)
	WHERE pgo.relkind =ANY('{r,i,t,m,G}')
)
SELECT ext_objs.objid FROM ext_objs
	JOIN cnst ON ext_objs.extname=ANY(cnst.exts)
    ORDER BY objid
;

В данной реализации предусмотрена возможность отключения механизма двухфазного обновления с помощью параметра утилиты pg_upgrade --no-two-phases. Использование этого ключа вернет pg_upgrade к оригинальному поведению.

Параметр -e, --two-phases-extensions позволяет задать свой список расширений, объекты которых попадут в первую фазу обработки. Порядок следования расширений в этом списке важен, так как обработка и попадание в дампы первой фазы будет идти как раз в порядке следования в списке слева-направо. Это важно, если одно расширение зависит от другого. Пример использования новых параметров:

pg_upgrade --old-bindir=/usr/pangolin-6.4/bin --new-bindir=/usr/pangolin-6.6/bin --new-bindirclient=/usr/pangolin-dbms-client-6.6/bin --old-datadir=/usr/pangolin-6.4/pgdata --new-datadir=/usr/pangolin-6.6/pgdata --retain --link --no-two-phases

pg_upgrade --old-bindir=/usr/pangolin-6.4/bin --new-bindir=/usr/pangolin-6.6/bin --new-bindirclient=/usr/pangolin-dbms-client-6.6/bin --old-datadir=/usr/pangolin-6.4/pgdata --new-datadir=/usr/pangolin-6.6/pgdata --retain --link --two-phases-extensions=fuzzystrmatch,postgis

warning

Использование вместе параметров --no-two-phases и --two-phases-extensions недопустимо и приведет к остановке работы утилиты pg_upgrade.

Различия в выводе можно увидеть здесь:

Журнал двухфазного обновления	Журнал однофазного обновления
Performing Consistency Checks	Performing Consistency Checks
Checking cluster versions ok	Checking cluster versions ok
Checking old cluster type Pangolin	Checking old cluster type Pangolin
Checking database user is the install user ok	Checking database user is the install user ok
Checking database connection settings ok	Checking database connection settings ok
Checking for prepared transactions ok	Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok	Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok	Checking for reg* data types in user tables ok
Checking for arrays of predefined domains in user tables ok	Checking for arrays of predefined domains in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok	Checking for contrib/isn with bigint-passing mismatch ok
Creating dump of global objects ok	Creating dump of global objects ok
Creating dump of extensions schemas	Creating dump of database schemas
ok	ok
Creating dump of database schemas excluding extensions	ok
ok
ok
Checking protection status ok	Checking protection status ok
Checking for presence of required libraries ok	Checking for presence of required libraries ok
Checking for hardlink for PG_VERSION ok	Checking for hardlink for PG_VERSION ok
Checking for hardlink for PRODUCT_VERSION ok	Checking for hardlink for PRODUCT_VERSION ok
Checking for hardlink for global/enc_keys.json is absent ok	Checking for hardlink for global/enc_keys.json is absent ok
Checking for hardlink for global/enc_settings.cfg is absent ok	Checking for hardlink for global/enc_settings.cfg is absent ok
Checking database user is the install user ok	Checking database user is the install user ok
Checking for prepared transactions ok	Checking for prepared transactions ok
Checking for new cluster tablespace directories ok	Checking for new cluster tablespace directories ok
If pg_upgrade fails after this point, you must re-initdb the	If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.	new cluster before continuing.
Performing Upgrade	Performing Upgrade
Analyzing all rows in the new cluster ok	Analyzing all rows in the new cluster ok
Freezing all rows in the new cluster ok	Freezing all rows in the new cluster ok
Deleting files from new pg_xact ok	Deleting files from new pg_xact ok
Copying old pg_xact to new server ok	Copying old pg_xact to new server ok
Setting oldest XID for new cluster ok	Setting oldest XID for new cluster ok
Setting next transaction ID for new cluster ok	Setting next transaction ID for new cluster ok
Deleting files from new pg_multixact/offsets ok	Deleting files from new pg_multixact/offsets ok
Copying old pg_multixact/offsets to new server ok	Copying old pg_multixact/offsets to new server ok
Deleting files from new pg_multixact/members ok	Deleting files from new pg_multixact/members ok
Copying old pg_multixact/members to new server ok	Copying old pg_multixact/members to new server ok
Setting next multixact ID and offset for new cluster ok	Setting next multixact ID and offset for new cluster ok
Resetting WAL archives ok	Resetting WAL archives ok
Moving TDE settings ok	Moving TDE settings ok
Setting frozenxid and minmxid counters in new cluster ok	Setting frozenxid and minmxid counters in new cluster ok
Restoring global objects in the new cluster ok	Restoring global objects in the new cluster ok
Pre-phase of restoring template1 schema in the new cluster ok	Restoring database template schemas in the new cluster
Pre-phase of copying user relation files	ok
ok
Restoring template1 schema in the new cluster ok
Copying user relation files
ok
Pre-phase of restoring no template1 db's schemas in the new cluster
ok
Pre-phase of copying user relation files
ok
Restoring no template1 db's schemas in the new cluster
ok
Merging TDE settings ok	Merging TDE settings ok
Adding ".old" suffix to old global/pg_control ok	Adding ".old" suffix to old global/pg_control ok
If you want to start the old cluster, you will need to remove	If you want to start the old cluster, you will need to remove
the ".old" suffix from /usr/pangolin-6.4/pgdata/global/pg_control.old.	the ".old" suffix from /usr/pangolin-6.4/pgdata/global/pg_control.old.
Because "link" mode was used, the old cluster cannot be safely	Because "link" mode was used, the old cluster cannot be safely
started once the new cluster has been started.	started once the new cluster has been started.
Linking user relation files	Linking user relation files
ok	ok
Setting next OID for new cluster ok	Setting next OID for new cluster ok
Sync data directory to disk ok	Sync data directory to disk ok
Creating script to delete old cluster ok	Creating script to delete old cluster ok
Checking for extension updates ok	Checking for extension updates ok
Upgrade Complete	Upgrade Complete
Optimizer statistics are not transferred by pg_upgrade.	Optimizer statistics are not transferred by pg_upgrade.
Once you start the new server, consider running:	Once you start the new server, consider running:
/usr/pangolin-dbms-client-6.6/bin/vacuumdb --all --analyze-in-stages	/usr/pangolin-dbms-client-6.6/bin/vacuumdb --all --analyze-in-stages
Running this script will delete the old cluster's data files:	Running this script will delete the old cluster's data files:
./delete_old_cluster.sh	./delete_old_cluster.sh