Ну, всегда есть место извращению с прокидыванием бинарников "на время".

Вопрос же не только в этом, а и том, больше это труда или меньше...

pg_upgrade обоих нужных версий будет внутри контейнера

"Каждую ночь база накатывает дампы с прода в временные базы, потом дропает оригиналы и делает переименование временных баз в оригинальные"

что простите ? Зачем ? Оо

2021-03-11 04:00:07,575296320 -> createdb -T template0 'tools_ui_12e5deb6'
createdb: database creation failed: ERROR:  database is not accepting commands to avoid wraparound data loss in database "template0"
HINT:  Stop the postmaster and vacuum that database in single-user mode.
You might also need to commit or roll back old prepared transactions.

закончился счетчик транзакций, кажется что-то не то с автовакуумом

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

ааа, ну тогда +- адекватно выглядит

2021-03-11 04:00:07,575296320 -> createdb -T template0 'tools_ui_12e5deb6'
createdb: database creation failed: ERROR:  database is not accepting commands to avoid wraparound data loss in database "template0"
HINT:  Stop the postmaster and vacuum that database in single-user mode.
You might also need to commit or roll back old prepared transactions.

Что-то это довольно странное. Какая полная версия PostgreSQL, для начала?

> Что такое wraparound data loss?

Вот это: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

> Как чинить? Запускать фулл вакуум на всех базах?

Нет, просто "VACUUM;" в template0, казалось бы... но дело в том, что этого не должно было случиться... там в template0 никто не вносил изменений и т.п.?

вот к примеру смотрите,
у меня для CI/CD тестовый образ с кучей постгресов внутри. По сути я могу запустить контейнер на основе этого образа, смонтировать в контейнер каталоги с БД, и выполнить pg_upgrade

Так, кажется я ваш исходный посыл не так прочёл, думал вы тома считаете слишком ненадёжными.

ПонЕл, отстал. Мал-мала тормознул, подумал, что два отдельных докера с двумя версиями, вижу, что неправ.

postgresql-staging-gce-sc-2/postgres # SELECT version();
                                               version                                               
-----------------------------------------------------------------------------------------------------
 PostgreSQL 9.6.9 on x86_64-pc-linux-gnu ( ), compiled by gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0, 64-bit

template0 никто не менял.
Также в логе я вижу вот такие предупреждения:

2021-03-11 08:36:57.456 UTC [21176] ERROR:  found xmin 203019837 from before relfrozenxid 481819908
2021-03-11 08:36:57.456 UTC [21176] CONTEXT:  automatic vacuum of table "template0.pg_catalog.pg_database"
2021-03-11 08:36:57.457 UTC [21176] WARNING:  database "template0" must be vacuumed within 1000000 transactions
2021-03-11 08:36:57.457 UTC [21176] HINT:  To avoid a database shutdown, execute a database-wide VACUUM in that database.
        You might also need to commit or roll back old prepared transactions.

ну там были разные истории лет 5 назад с крэшами и коррупциями, но сейчас вроде все устаканилось, лично мне кажется что оно вполне стабильное. Разве что могут быть риски при использовании различных реализаций PersistentVolume для kubernetes, но это как я понимаю отдельная прослойка к волюмам не имеет прямого отношения.

мне только непонятно что вакуумировать в template0 там ведь нет таблиц.

Выхлоп pg_test_fsync

да, вцелом можно под любые нужды нагородить себе любой огород на вкус и цвет )))

И вот конфиг

max_connections = 200
shared_buffers = 4GB
effective_cache_size = 12GB
maintenance_work_mem = 1GB
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 4
effective_io_concurrency = 2
work_mem = 5242kB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

Вакуум в template0 выдаёт ошибку:

postgresql-staging-gce-sc-2/template0 # VACUUM ;
ERROR:  XX001: found xmin 203019837 from before relfrozenxid 481819908
LOCATION:  heap_prepare_freeze_tuple, heapam.c:6699

postgresql-staging-gce-sc-2/template0 # VACUUM ;
ERROR:  XX001: found xmin 203019837 from before relfrozenxid 481819908
LOCATION:  heap_prepare_freeze_tuple, heapam.c:6699

версия базы какая?

Я писал выше, 9.6.9.