hubert depesz lubaczewski wrote: > On Thu, Aug 25, 2011 at 04:33:07PM -0400, Bruce Momjian wrote: > > 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'; > > $ SELECT reltoastrelid FROM pg_class WHERE relname = 'actions'; > reltoastrelid > --------------- > (0 rows) > > This is done not on the pg from backup, but on normal production, as the test > pg instance doesn't work anymore. > > I can re-set the test instance, but extracting from backup, and making it > apply > all xlogs usually takes 2-3 days.
If you remove the .old extension on pg_control, you can start the old cluster and check it. This is explained by pg_upgrade output: | If pg_upgrade fails after this point, you must | re-initdb the new cluster before continuing. | You will also need to remove the ".old" suffix | from /var/postgresql/6666/global/pg_control.old. Please check the old cluster. > > > 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? > > It was done definitely using 9.0.4. Good. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers