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

Reply via email to