Re: proposal: a validator for configuration files
От | Florian Pflug |
---|---|
Тема | Re: proposal: a validator for configuration files |
Дата | |
Msg-id | B31B70C7-FB4F-4721-92E7-AFBA96511322@phlo.org обсуждение исходный текст |
Ответ на | Re: proposal: a validator for configuration files (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: proposal: a validator for configuration files
|
Список | pgsql-hackers |
On Jul16, 2011, at 21:23 , Tom Lane wrote: > Florian Pflug <fgp@phlo.org> writes: >> On the downside, the current behaviour prevents problems if someone changes >> two interrelated GUCs, but makes a mistake at one of them. For example, >> someone might drastically lower bgwriter_delay but might botch the matching >> adjustment of bgwriter_lru_maxpages. > > That's a fair point, but the current behavior only saves you if the > botch is such that the new value is detectably invalid, as opposed to > say just a factor of 100 off from what you meant. Not sure that that's > all that helpful. True. And a forgotten zero or wrong unit probably is even more likely than a totally botched value. So +1 from me. Btw, if we touch that, I think we should think about providing some way to detect when a backend fails to apply a value. Showing the precise option that caused the trouble is probably hard, but could we add a flag to PGPROC that gets set once a backend fails to apply some setting on SIGUP? If we showed the state of such a flag in pg_stat_activity, it'd give an admin a quick way of verifying that all is well after a SIGUP. We might also want to record the timestamp of the last processed file so that backends which haven't yet processed the SIHUP can also be detected. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: