Re: [GENERAL] pg_upgrade problem

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +