Andrew Sullivan <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
