On 9/26/14, 2:17 PM, Tom Lane wrote:
> Well, ok, let's allow zero as a special case, but it has to be written
> as "0" not something else. If you try to set a positive value then we
> should act as though the min_val is 1 unit. So I'm coming around to
> the idea that "throw an error if a nonzero input would round (or
> truncate) to zero" is a reasonable solution.
I expressed some distaste for throwing errors before, but I find this
specific rule reasonable. I'll even write the patch. I owe the GUC
system a re-match after my wal_buffers auto-scaling thing for 9.1
rippled to cause extra work for you (maybe Robert too).
I just changed this submission from "Ready for Committer" to "Returned
with Feedback", with the feedback being that we'd like to see special
values rounded to 0 treated differently altogether first, before
touching any rounding. And that's a whole new submission for the next CF.
> I think it'd be even more reasonable if we also fixed the rounding
> rule to be "round to nearest", but the two changes can be considered
> independently. regards, tom lane
Personally I'm still -1 on any rounding change, instead preferring to
work toward eliminating these 0 & -1 special values altogether. Outside
of these special cases, I feel you are fundamentally right that if the
rounding really matters, the unit is simply too large. And I believe
that is the case for the log rotation one right now.
I can see my idea for rescaling the rotation age parameter is an
unpopular one, but I still like it. That cleanly splits out into a
third thing though, where it can live or die without being tied to the
rest of these issues.
--
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/