Re: "failed to re-find parent key" question

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "failed to re-find parent key" question
Дата
Msg-id 26500.1173155386@sss.pgh.pa.us
обсуждение исходный текст
Ответ на "failed to re-find parent key" question  ("Roger Pan" <roger.pan@nexustelecom.com>)
Список pgsql-admin
"Roger Pan" <roger.pan@nexustelecom.com> writes:
>    We use postgreSQL 8.1.2 in Solaris 9 platform  to maintain very =
> important business data.

If it's as important as all that, you should make more of an effort to
keep up-to-date with PG minor releases...

> PANIC:  failed to re-find parent key in "1560660"
>  I know  the problem " failed to re-find parent key" has been fixed in =
> the newer release. My question is how we can recover the data in this =
> case? The difficult is the disk with postgres data system is full.=20

A quick and dirty solution would be to do pg_resetxlog, but the problem
is that it's difficult to predict how much corruption or data loss would
result.  If the data is really worth an effort to save, you might consider
making a hacked-up build in which this PANIC is reduced to a WARNING,
which you use just long enough to boot up and shut down.  I think it'd
work to change (in src/backend/access/nbtree/nbtinsert.c)

        /* Check for error only after writing children */
        if (pbuf == InvalidBuffer)
            elog(ERROR, "failed to re-find parent key in \"%s\"",
                 RelationGetRelationName(rel));

        /* Recursively update the parent */
        _bt_insertonpg(rel, pbuf, stack->bts_parent,
                       0, NULL, new_item, stack->bts_offset,
                       is_only);

to

        /* Check for error only after writing children */
        if (pbuf == InvalidBuffer)
            elog(WARNING, "failed to re-find parent key in \"%s\"",
                 RelationGetRelationName(rel));
        else
        /* Recursively update the parent */
        _bt_insertonpg(rel, pbuf, stack->bts_parent,
                       0, NULL, new_item, stack->bts_offset,
                       is_only);

After that, reboot into a standard postmaster, and reindex
the index(es) identified by the warning messages.

After that, think about an update ;-)

            regards, tom lane

PS: if you try this, I'd *strongly* suggest first making a
filesystem-level backup of all of the $PGDATA tree, so that you aren't
any worse off if it doesn't work.

В списке pgsql-admin по дате отправления:

Предыдущее
От: "Phillip Smith"
Дата:
Сообщение: Re: pg_hba.conf & putty
Следующее
От: "Moritz Bayer"
Дата:
Сообщение: Re: pg_hba.conf & putty