Description of problem:
The issue tracker database recently had an outage wherein Postgres
refused to restart from a failure because it encountered a bad LSN
(WAL pointer) in one of the pages touched during recovery. Due to
arguably-overly-paranoid initial programming of the WAL code, this
was treated as a PANIC condition instead of something less severe.
The community backed off the error severity in PG 7.2, but it was
never back-patched into community 7.1.
I got the issue tracker folk out of hot water by back-patching the
reduction of error level from community 7.2, and I'm now thinking
it's advisable to make that part of our regular release for 2.1AS.
Complaining about corrupt data is all well and good, but refusing
to play ball at all is not cool.
Version-Release number of selected component (if applicable):
100% given suitably corrupt data.
Steps to Reproduce:
1. Gun a running server (eg kill -9 postmaster and its children).
2. Put garbage in the first 8 bytes of any recently-modified page.
3. Try to restart server.
Database startup aborts.
Startup should produce a complaint message but keep going.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.