Я нахожусь в процессе обновления pg_upgrade с 8.4 до 9.3. Я использую эту технику:
http://momjian.us/main/writings/pgsql/pg_upgrade.pdf
Обновление выполняется уже 250 часов, а определение базы данных сохраняется на шаге уже 160 часов. Это текущий вывод последних нескольких строк strace:
poll([{fd=5, events=POLLIN|.
POLLERR}], 1, -1) = 1 ([{fd=5,
revents=POLLIN}])
recvfrom(5, "T\0\0\0F
\0\2reltoastrelid\0\0\0\4\353\0\n
\0\0\0\32\0"..., 16384, 0, NULL,
NULL) = 122
(5, "Q\0\0\0\221SELECT
attname, attacl FROM"..., 146,
MSG_NOSIGNAL, NULL, 0) = 146
poll([{fd=5, events=POLLIN|
POLLERR}], 1, -1
Есть ли способ оценить, сколько времени это займет? В pg_class около 3 300 000 объектов, а в базе данных около 765 000 таблиц. В большинстве таблиц около 3-5 столбцов, а всего около 2 000 000 записей.
pg_upgrade
должен быть очень быстрым. Несмотря на то, что у вас много таблиц, у вас нет действительно огромных данных (2kk в настоящее время не так уж и много). Я думаю, вам следует попробовать выполнить дамп/восстановление на отдельной машине. У вас действительно есть какая-либо системная активность, такая как дисковый ввод-вывод или использование ЦП? Или там что-то закрыто? - person Vinícius Gobbo A. de Oliveira   schedule 08.10.2014pg_upgrade
будет использоватьpg_dump
9.3, поэтому он должен быть в текущем выпуске. К OP: вы должны посмотреть, можете ли вы подключиться к сокету, который он использует, и взглянуть наpg_stat_activity
. Мое предложение: postgresql.org/support/professional_support . - person Craig Ringer   schedule 08.10.2014pg_dump
этой базы данных? - person Craig Ringer   schedule 08.10.2014pg_dump
9.3 не поможет решить эту конкретную проблему, это будет только при будущих обновлениях. - person Daniel Vérité   schedule 08.10.2014