"Roger Pan" <roger.pan@xxxxxxxxxxxxxxxx> 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.
