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.sm...@crunchydatasolutions.com Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
