Hide Forgot
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:
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. http://rhn.redhat.com/errata/RHBA-2005-240.html