LINUX.ORG.RU
Форум — Development  

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

 


0

2

Подскажите пожалуйста, столкнулся с проблемой после обновления версии PostgreSQL с 9.6 на 15.3 для БД разрабатываемого приложения. Суть проблемы в том что простой скрипт на удаление данных из таблицы работает медленнее и работа приложения завершается ошибкой: org.postgresql.util.PSQLException: ВАЖНО: закрытие подключения по команде администратора. При этом если откатить СУБД обратно приложение работает корректно. Проблемный скрипт имеет вид: «DELETE FROM db.table_name WHERE id = ?»; Таблица максимально простая, индексов и триггеров не имеет.

Подскажите в какую сторону смотреть, буду благодарен любым советам.

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

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 1)
Ответ на: комментарий от mx__

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

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 1)
Ответ на: комментарий от etwrq

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

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

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

mx__ ★★★★★
()
Ответ на: комментарий от mx__

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

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 3)
Ответ на: комментарий от etwrq

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

begginner
() автор топика

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

vbr ★★★
()
Ответ на: комментарий от etwrq

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

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

arkhnchul ★★
()
Последнее исправление: arkhnchul (всего исправлений: 1)
Ответ на: комментарий от arkhnchul

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

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 2)

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

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

WHERE id = ?

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

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

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

Toxo2 ★★★★
()
Development