Re: Detecting corrupted pages earlier - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Detecting corrupted pages earlier
Date
Msg-id 16634.1049413254@sss.pgh.pa.us
Whole thread Raw
In response to Re: Detecting corrupted pages earlier  (Vincent van Leeuwen <pgsql.spam@vinz.nl>)
Responses Re: Detecting corrupted pages earlier  (Vincent van Leeuwen <pgsql.spam@vinz.nl>)
List pgsql-hackers
Vincent van Leeuwen <pgsql.spam@vinz.nl> writes:
> ... This cost us about 10 hours downtime. If I'd had the option I just
> would've set ZERO_DAMAGED_PAGES to true and let it run for a few days to sort
> itself out.

Yikes.  If I understand this correctly, you had both critical data and
cache data in the same database.  As for the cache stuff, a few quick
TRUNCATE TABLE commands would have gotten you out of the woods.  As for
the critical data (the stuff you actually needed to dump and restore),
do you really want ZERO_DAMAGED_PAGES on for that?  It's a heck of a
blunt tool.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Vincent van Leeuwen
Date:
Subject: Re: Detecting corrupted pages earlier
Next
From: Vincent van Leeuwen
Date:
Subject: Re: Detecting corrupted pages earlier