Re: [SPAM] Re: BUG #3484: Missing pg_clog file / corrupt index - Mailing list pgsql-bugs

From Gregory Stark
Subject Re: [SPAM] Re: BUG #3484: Missing pg_clog file / corrupt index
Date
Msg-id 87wsvky73h.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [SPAM] Re: BUG #3484: Missing pg_clog file / corrupt index  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> It's still pointless; a checksum does nothing to prevent data
> corruption.  The error report might be slightly more obvious to a novice
> but it doesn't bring your data back.

Well if it's a single bit error from bad memory or a torn page from having
full_page_writes turned off then the resulting page could be entirely valid.
The user might not find out about the corrupt data before it's had time to
migrate elsewhere.

Also, the sooner the corrupt data is reported the sooner the user can restore
from backups and avoid further data loss. The last discussion of this feature
concentrated on beingg able to detect torn page corruption with
full_page_writes turned off during recovery.

> Something we could possibly do now is to modify these error messages:
> if the transaction number we're trying to check is obviously bogus
> (beyond the current XID counter or older than the current freeze
> horizon) we could report it as a corrupted XID rather than exposing
> the "no such clog segment" condition.

That would be clever. I take it you mean the invalid values would be those
values older than the actual relfrozenxid. Certainly they should throw some
sort of error instead of trying to find the transaction in the clog.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [SPAM] Re: BUG #3484: Missing pg_clog file / corrupt index
Next
From: Bruce Momjian
Date:
Subject: Re: [SPAM] Re: BUG #3484: Missing pg_clog file / corrupt index