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