Re: [GENERAL] pg_upgrade problem
От | Bruce Momjian |
---|---|
Тема | Re: [GENERAL] pg_upgrade problem |
Дата | |
Msg-id | 201108252033.p7PKX7629929@momjian.us обсуждение исходный текст |
Ответы |
Re: [GENERAL] pg_upgrade problem
|
Список | pgsql-hackers |
hubert depesz lubaczewski wrote: > hi > > I have 8.3.11 database, ~ 600GB in size. > > I want to upgrade it to 9.0. > > First, I tried with 9.0.4, and when I hit problem (the same) I tried > git, head of 9.0 branch. Good. > pg_upgrade_dump_db.sql- > pg_upgrade_dump_db.sql--- For binary upgrade, must preserve relfilenodes > pg_upgrade_dump_db.sql-SELECT binary_upgrade.set_next_heap_relfilenode('71637068'::pg_catalog.oid); > pg_upgrade_dump_db.sql:SELECT binary_upgrade.set_next_toast_relfilenode('71637071'::pg_catalog.oid); > pg_upgrade_dump_db.sql-SELECT binary_upgrade.set_next_index_relfilenode('71637073'::pg_catalog.oid); > pg_upgrade_dump_db.sql- > pg_upgrade_dump_db.sql-CREATE TABLE actions ( > -- > pg_upgrade.log-linking /var/postgresql/6666/base/113953649/2613 to /var/postgresql/6666-9.0/base/11826/11790 > pg_upgrade.log- /var/postgresql/6666/base/113953649/2683 > pg_upgrade.log-linking /var/postgresql/6666/base/113953649/2683 to /var/postgresql/6666-9.0/base/11826/11792 > pg_upgrade.log:Could not find 71637071 in old cluster The problem appears to be that the Postgres catalogs think there is a toast table for 'actions', while the file system doesn't seem to have such a file. I can you look in pg_class and verify that? SELECT reltoastrelid FROM pg_class WHERE relname = 'actions'; Then look in the file system to see if there is a matching file. > One more thing - one of earlier tests actually worked through > pg_upgrade, but when running vacuumdb -az on newly started 9.0.4, I got > error about missing transaction/clog - don't remember exactly what it > was, though. THere was a bug in how how pg_upgrade worked in pre-9.0.4 --- could it have been that? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: