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

On Thu, Sep 25, 2014 at 12:11 AM, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>
wrote:

> 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.
>

​Why? Do you agree that a log_rotation_age value defined in seconds is
sane? If your reasoning is that everything else is defined in "s" and "ms"
then that is a developer, not a user, perspective. I'll buy into the
"everything is defined in the smallest possible unit" approach - in which
case the whole rounding things becomes a non-issue - but if you leave some
of these in seconds then we should still add an error if someone defines an
insane millisecond value for those parameters.​

>
> 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)
> ​​
>
>
​Maybe I'm nieve but I'm seriously doubting this. From what I can tell the
rounding isn't currently documented and really doesn't need much if any to
be added. An error instead of rounding down to zero ​would be sufficient
and self-contained. "The value specified is less than 1 in the parameter's
base unit"

>
> 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.
>

​You've already admitted there will be breakage. Your argument is that it
will be obvious enough to notice. Why not just make it impossible?
​

>
> 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.
>
>
Maybe not: I contend the root problem is that while we provide sane unit
specifications we've assumed that people will always be providing values
greater than 1 - but if they don't we silently use zero (a special value)
instead of telling them they messed up (made an error). If the presence of
config.d and such make this untenable then I'd say those features have a
problem.- not our current choice to define what sane is.

David J.