Долгое выполнение скрипта после обновления версии PostgreSQL с 9.6 на 15.3

drop & rebuild indexes;
reimport data via sql;
два инстанса, из одного в другой перегоняете через SQL, в максимально совместимом виде.
потом уже нужные фишки примените на пятнашке.

Да ладно, не верю что он бд обновил без бекапа БД и последующего ее востановления.

vacuum full analyze

такой гэп вроде не покрывается через sudo $packet_manager upgrade.
я за clear data/structure movement.
это 6-мажор ап, даже дебиан так не может.

А мозги ему на что ?

P.S. Версии pg 9.6 и 15 попахивают 1с-кой.

для какого-нибудь внутреннего энтерпрайза сойдёт и 9.6, к сегодняшнему дню всё уже будет боле-мене вылизано, и выдавать 30к-40к рпс на среднем железе.

Для энтерпрайза сойдет, для 1с уже нет, если хотят новую конфигурацию поюзать …

Я всегда думал что postscript apt будет предлагать запускать что то подобное : pg_upgrade

Хотя версии 9х и 15х уж очень далеки от друга, я бы без фулл бекапа БД не рискнул бы.

ну можно, абстрактно,
сделать структурный и функциональный клон прода, за-seed-ить его рандомом.
и уже играться.
с другой стороны не понимаю с 9 на 15 резко [и «эффективно»] взлетать?
тогда лучше 16, там вроде динамическая аллокация дата-файлов - бд обратно после truncate/delete место в ос возвращает, ну и +фиксы/нештяки.
всеравно всё к этому идёт:
DBFS

Приложение подтягиволось под новые версии PostgreSQL, но клиент обновление игнорировал и решил обновится только недавно на актуальную на то время версию 15.3 Обновление делалось через фул бэкап

а вы там бесплатно у греков соль отымаете?
если data egret ваши, вы всёравно должны учитывать и этот кейс

Может место кончается?

Лучше бы это под английской локалью запустить. Русские сообщения об ошибке гуглить это такое себе.

Попробуй отключить авто вакуум.

Но вообще я ставлю на всякие оомкиллеры. Скорей всего твой запрос жрет слишком много памяти и процесс прибивается.

даже дебиан так не может

точно? Если правильно помню, что что-то типа такого я там делал однажды. Дебиановский pg_upgradecluster делает как раз примерно то же, что и админ руками - вешает старый кластер на свободный порт, поднимает пустой новый кластер на 5432 и гоняет pg_dump через пайп из старого в новый. Старый кластер после этого тормозится, но не удаляется, все данные лежат как были.

там с 6 на 9 ку, были проблемы с deb/apt/libc - я упомянул именно в этом контексте.
а бд самое простое гонять - это через SQL+max_compat[в идеале по стандарту], а потом уже фишки/оптимизации на новой субд лепить.
есть конечно pg_basebackup[-pro]/wal-g, но кому интересны hidden-errors-in-blobs?

ВАЖНО: закрытие подключения по команде администратора

это точно принудительное завершение сессии, вполне может быть действительно OOM Killer. Или statement_timeout, возможно.

WHERE id = ?

Нет такого placeholder в PG. Если оно у вас так работает - значит есть какая-то ещё прослойка перед PG.

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

Включите лог запросов - посмотрите что там на самом деле до ПГ долетает.