Re: Failure upgrading PG 9.2 to 9.3

Поиск
Список
Период
Сортировка
От Sam Saffron
Тема Re: Failure upgrading PG 9.2 to 9.3
Дата
Msg-id CAAtdryOhp4nWnNBUG4Y5zi2N299H-bUBoQ8yf0EWKkeak=m+ug@mail.gmail.com
обсуждение исходный текст
Ответ на 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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Failure upgrading PG 9.2 to 9.3  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список 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 по дате отправления:

Предыдущее
От: Steven Schlansker
Дата:
Сообщение: Re: Trimming transaction logs after extended WAL archive failures
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Failure upgrading PG 9.2 to 9.3