Re: Failure upgrading PG 9.2 to 9.3

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Sam Saffron <sam(dot)saffron(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Failure upgrading PG 9.2 to 9.3
Date: 2014-03-25 23:58:38
Message-ID: 5332182E.8060702@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 03/25/2014 04:32 PM, Sam Saffron wrote:
> 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.

Hmm, so I am still unclear on this. The 'corrupt' database is the one
you upgraded away from or to? If to I am not sure you have solved
anything. For the sake of discussion I am assuming you did a pg_dump on
the 9.2 instance and a restore on the 9.3 instance. Is this correct?

>
> Cheers
> Sam
>
> On Wed, Mar 26, 2014 at 3:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Sam Saffron <sam(dot)saffron(at)gmail(dot)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
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sam Saffron 2014-03-26 00:03:55 Re: Failure upgrading PG 9.2 to 9.3
Previous Message Steven Schlansker 2014-03-25 23:52:43 Re: Trimming transaction logs after extended WAL archive failures