> When doing a recover in a single-user backend we get the following
> error:
> $ postgres -D /var/lib/pgsql/data/ test
> PANIC: block 24929 unfound
This looks like it is probably a case of a design problem that was fixed
in 8.2: the WAL replay code wasn't prepared for the case of finding an
update record for a page that was since truncated away (or its table was
dropped entirely).
FWIW, the only exact matches to that message spelling that I can find in
the 8.1 sources are in gistxlog.c, so this problem is evidently
corruption in a GIST index. Dunno if that information is of any help.
But the real problem is that since the recovery is aborting here, no
other corrections from WAL are getting applied, so anything else that
was changed lately is also at risk.
The only recovery strategy that I can think of in 8.1 is to blow away
your WAL with pg_resetxlog, let the database come up in a damaged
condition, and then try to extract data from it. The best bet would be
to try to get a complete pg_dump out of it, and then initdb and reload;
since you don't know exactly what's been corrupted, you should not try
to go back into production without an initdb/reload.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
No comments:
Post a Comment