Да это всё понятно. Я спросил тут, потому что сейчас

Question

Да это всё понятно. Я спросил тут, потому что сейчас

проблема выглядит именно с PG: в DB2 пропавших индексов типа нету, но по результатам выполнения запроса они кагбэ работают. У меня мало опыта с PG, поэтому для меня это выглядит как мистика.

Но в целом, правильно ли я понял, что:
pg_dumpall |psql должен перенести все данные-роли-индексы в свежую базуданных на новом сервере, но после изначального импорта всё равно желательно сделать vacuum clean? (это лишние несколько часов при апгрейде)

#backend #devops #pgsql #programming #russian

0

14.05.2020

1 ответов

9 просмотров

Yaroslav Schekin · Accepted Answer

> в DB2 пропавших индексов типа нету, но по результатам выполнения запроса они кагбэ работают. Так Вы какой-то конкретный индекс, которого "как бы нету", можете найти? > поэтому для меня это выглядит как мистика. Для меня — тоже, а какой-то опыт работы у меня есть. ;) Поэтому и нужно найти что-то конкретное, чтобы можно было показать и посмотреть. > pg_dumpall |psql должен перенести все данные-роли-индексы в свежую базуданных на новом сервере Всё он должен перенести, т.е. все пользовательские базы данных (со всем, что в них есть), роли и настройки. А Вы точно правильно это делали (и почему Вы не пользуетесь pg_upgrade, кстати?) — нужно снимать дамп именно новой версией pg_dumpall со старого сервера, обратите внимание. > но после изначального импорта всё равно желательно сделать vacuum clean? Никакого VACUUM clean не существует. Нужно либо выполнить (под superuser): VACUUM ANALYZE; В каждой базе, либо использовать для этого же vacuumdb, см. manual. > это лишние несколько часов при апгрейде Что поделаешь — при "нормальном" upgrade это обычно делается поэтапно (но всё равно база вначале может подтормаживать, да) — см. документацию pg_upgrade и т.п.

172 похожих чатов

Да это всё понятно. Я спросил тут, потому что сейчас

1 ответов

Похожие вопросы