"Roger Pan" <[EMAIL PROTECTED]> 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.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to