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(dot)smith(at)crunchydatasolutions(dot)com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/