Re: Detecting corrupted pages earlier
От | Kevin Brown |
---|---|
Тема | Re: Detecting corrupted pages earlier |
Дата | |
Msg-id | 20030402204447.GM1833@filer обсуждение исходный текст |
Ответ на | 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). Hmm...I don't know that I'd want to go that far -- setting this variable could be regarded as a policy decision. Some shops may have very good reason for running with ZERO_DAMAGED_PAGES enabled all the time, but I don't know what those reasons might be. But the fact that I can't think of a good reason isn't sufficient cause to remove that as an option. I would definitely be in favor of issuing a warning ("Running with ZERO_DAMAGED_PAGES enabled will cause you to lose possibly recoverable data whenever a damaged page is encountered. Be sure you know what you're doing") whenever the variable is set, whether it be at startup or during a session. -- Kevin Brown kevin@sysexperts.com
В списке pgsql-hackers по дате отправления: