"Wouter Sergeyssels" <Wouter@xxxxxxxxxx> writes: > 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
