Re: recover in single-user backend fails

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Wouter Sergeyssels" <Wouter(at)nucleus(dot)be>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: recover in single-user backend fails
Date: 2008-09-06 20:54:24
Message-ID: 25015.1220734464@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Wouter Sergeyssels" <Wouter(at)nucleus(dot)be> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Randal T. Rioux 2008-09-06 22:39:26 64-bit Compile Failure on Solaris 10 with OpenSSL
Previous Message Bruce Momjian 2008-09-06 19:30:57 Re: Subqueries in Check() -- Still Intentionally Omitted?