Thread: recover in single-user backend fails
Hello,
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
Aborted.
All this was the result of an unclean postmaster shutdown while running a VACUUM in single-user backend.
PGVERSION=8.1.6
DB SIZE= +- 7GB
Thank you for the input!
Regards,
Wouter S.
"Wouter Sergeyssels" <Wouter@nucleus.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
Tom Lane <tgl@sss.pgh.pa.us> writes: > 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. Would it work if he rebuilt 8.1 with a "return;" as the first line of gist_redo() in gistxlog.c and when recovery (hopefully) completes immediately drop any gist indexes? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
Hey Guys, Thanks for your input. Meanwhile we have recovered from a backup. Lesson of all this, upgrade asap to postgres 8.2? Thanks, WS. -----Original Message----- From: Greg Stark [mailto:greg.stark@enterprisedb.com] On Behalf Of Gregory Stark Sent: zondag 7 september 2008 11:50 To: Tom Lane Cc: Wouter Sergeyssels; pgsql-general@postgresql.org Subject: Re: recover in single-user backend fails Tom Lane <tgl@sss.pgh.pa.us> writes: > 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. Would it work if he rebuilt 8.1 with a "return;" as the first line of gist_redo() in gistxlog.c and when recovery (hopefully) completes immediately drop any gist indexes? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
On Mon, Sep 8, 2008 at 4:34 AM, Wouter Sergeyssels <Wouter@nucleus.be> wrote: > Hey Guys, > > Thanks for your input. Meanwhile we have recovered from a backup. > > Lesson of all this, upgrade asap to postgres 8.2? Close, but I'd change that to 8.3.3 myself.