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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
