Re: Detecting corrupted pages earlier
От | Bruce Momjian |
---|---|
Тема | Re: Detecting corrupted pages earlier |
Дата | |
Msg-id | 200304022034.h32KYnQ19987@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Detecting corrupted pages earlier (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Detecting corrupted pages earlier
|
Список | pgsql-hackers |
Tom Lane wrote: > Kevin Brown <kevin@sysexperts.com> writes: > > Tom Lane wrote: > >> Basically, one should only turn this variable on after giving up on the > >> possibility of getting any data out of the broken page itself. It would > >> be folly to run with it turned on as a normal setting. > > > This statement should *definitely* go into the documentation for the > > option, then... > > Andrew Sullivan expressed concern about this, too. The thing could > be made a little more failsafe if we made it impossible to set > ZERO_DAMAGED_PAGES to true in postgresql.conf, or by any means other > than an actual SET command --- whose impact would then be limited to > 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). > > Comments? Perhaps better would be to throw a message message any time it is turned on, reminding them it should not be left on. Is that cleaner? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: