David,
* David Johnston (david.g.johnston@gmail.com) wrote:
> This is 9.5 material because 1) it isn't all that critical and, 2) we DO
> NOT want a system to not come up because of a GUC paring error after a
> minor-release update.
Agreed.
> I don't get where we "need" to do anything else besides that...the whole
> "actual min values" comment is unclear to me.
Well, for cases that allow going to zero as an "off" option, we've
already decided, I believe, that sub-1-unit options are off the table
and so the min value is at *least* 1, but there could be cases where '1'
doesn't actually make any sense and it should be higher than that.
Consider the log file rotation bit. If it was in seconds, would it
actually make sense to support actually doing a rotation *every second*?
No.
In that case, perhaps we'd set the minimum to '60s', even though
technically we could represent less than that, it's not sensible to do
so. The point of having minimum (and maximum..) values is that typos
and other mistakes happen and we want the user to realize they've made a
mistake.
What needs to happen next is a review of all the GUCs which allow going
to zero and which treat zero as a special value, and consider what the
*actual* minimum value for those should be (excluding zero). I was
hoping you might be interested in doing that... :D
Thanks,
Stephen
