Re: proposal: rounding up time value less than its unit.

On 9/24/14, 6:45 PM, Peter Eisentraut wrote:
> But then this proposal is just one of several others that break backward
> compatibility, and does so in a more or less silent way.  Then we might
> as well pick another approach that gets closer to the root of the problem.

I was responding to some desire to get a quick fix that cut off the 
worst of the problem, and the trade-offs of the other ideas bothered me 
even more.  Obvious breakage is annoying, but small and really subtle 
version to version incompatibilities drive me really crazy. A 60X scale 
change to log_rotation_age will be big enough that impacted users should 
definitely notice, while not being so big it's scary.  Rounding 
differences are small enough to miss.  And I do see whacking the sole 
GUC that's set in minutes, which I was surprised to find is a thing that 
existed at all, as a useful step forward.

I can't agree with Stephen's optimism that some wording cleanup is all 
that's needed here.  I predict it will be an annoying, multiple commit 
job just to get the docs right, describing both the subtle rounding 
change and how it will impact users.  (Cry an extra tear for the 
translators)

Meanwhile, I'd wager the entire work of my log_rotation_scale unit 
change idea, from code to docs to release notes, will take less time 
than just getting the docs done on any rounding change.  Probably cause 
less field breakage and confusion in the end too.

The bad case I threw out is a theorized one that shows why we can't go 
completely crazy with jerking units around, why 1000:1 adjustments are 
hard.  I'm not actually afraid of that example being in the wild in any 
significant quantity.  The resulting regression from a 60X scale change 
should not be so bad that people will suffer greatly from it either.  
Probably be like the big 10:1 change in default_statistics_target.  
Seemed scary that some people might be nailed by it; didn't turn out to 
be such a big deal.

I don't see any agreement on the real root of a problem here yet. That 
makes gauging whether any smaller change leads that way or not fuzzy.  I 
personally would be fine doing nothing right now, instead waiting until 
that's charted out--especially if the alternative is applying any of the 
rounding or error throwing ideas suggested so far.  I'd say that I hate 
to be that guy who tells everyone else they're wrong, but we all know I 
enjoy it.

-- 
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/