Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 2.1 product line. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 149760

Summary:	PostgreSQL 7.1 won't restart if it encounters corrupt data
Product:	Red Hat Enterprise Linux 2.1	Reporter:	Tom Lane <tgl>
Component:	postgresql	Assignee:	Tom Lane <tgl>
Status:	CLOSED ERRATA	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.1	CC:	hhorak
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-04-28 15:24:05 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tom Lane 2005-02-25 23:12:48 UTC

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:

Comment 1 John Flanagan 2005-04-28 15:24:05 UTC

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