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):
7.1.3-6.rhel2.1AS

How reproducible:
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.
  
Actual results:
Database startup aborts.

Expected results:
Startup should produce a complaint message but keep going.

Additional info: