Re: Detecting corrupted pages earlier

Andrew Sullivan <andrew(at)libertyrms(dot)info> writes:

> On Wed, Apr 02, 2003 at 03:25:58PM -0500, Tom Lane wrote:
>
> > the current session. This is kind of an ugly wart on the GUC mechanism,
> > but I think not difficult to do with an assign_hook (it just has to
> > refuse non-interactive settings).
>
> It may be an ugly wart, but I think it's only prudent. I'd be
> willing to bet a fair amount that there is a significant overlap
> between the population which uses Bob's Discount Hardware for 10
> million row, ultra-critical databases and the population which likes
> to twiddle postgresql.conf settings without reading the fine
> manual. Those folks are going to get burned by this setting unless
> it is very hard to turn on. (I think the setting is an excellent
> idea, though, for emergency cases.)
>
> I don't usually like making servers totally idiot-proof, but I can
> just imagine the Slashdot conversations after 7.4 comes out (and for
> at least 60 or 70 years thereafter): "PostgreSQL just randomly zeroes
> a page of data! It sucks! Use MySQL instead. It can recover from
> bad pages on your disk by randomly making up data for you, instead of
> just writing zeros."

Perhaps the real answer is to use a more *descriptive* name for the
variable than ZERO_DAMAGED_PAGES. Something along the lines of
CLUELESS_DBA_ESCHEWS_BACKUPS, or ONLY_AN_IDIOT_SETS_THIS_VARIABLE.
You don't have to read the manual to see that these variables are not
to be trifled with.

There are some cases where this particular feature would be useful.
What needs to be done is to make the feature less dangerous to the
newbie without making it less useful to the person who actually needs
the functionality.

Jason