Re: Failure upgrading PG 9.2 to 9.3 - Mailing list pgsql-general

From Sam Saffron
Subject Re: Failure upgrading PG 9.2 to 9.3
Date
Msg-id CAAtdryOhp4nWnNBUG4Y5zi2N299H-bUBoQ8yf0EWKkeak=m+ug@mail.gmail.com
Whole thread Raw
In response to Re: Failure upgrading PG 9.2 to 9.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Failure upgrading PG 9.2 to 9.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Failure upgrading PG 9.2 to 9.3  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
Thanks heaps Tom,

I can confirm corrupt db upgrades fine with pg_dump. Was wondering if
there are any plans to add a --no-validate to pg_upgrade, since the
crash seems only to happen during validation.

Cheers
Sam

On Wed, Mar 26, 2014 at 3:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sam Saffron <sam.saffron@gmail.com> writes:
>> Why would
>> "ERROR:  operator does not exist: name !~ unknown"
>> Come up ?
>
> It's hard to explain that as anything except corrupted system catalogs
> in your existing database :-(.  If you were really lucky, reindexing
> pg_operator would fix it; but since pg_operator is usually pretty static,
> it seems unlikely that it suffered index corruption.
>
>> Any way to work around this?
>
> Rather than relying on pg_upgrade, you could try using pg_dump(all)
> to extract the data.  With some luck, pg_dump wouldn't be affected by
> whatever has happened to the pg_operator catalog.
>
>                         regards, tom lane


pgsql-general by date:

Previous
From: Steven Schlansker
Date:
Subject: Re: Trimming transaction logs after extended WAL archive failures
Next
From: Tom Lane
Date:
Subject: Re: Failure upgrading PG 9.2 to 9.3