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

Поиск
Список
Период
Сортировка
От David Johnston
Тема Re: proposal: rounding up time value less than its unit.
Дата
Msg-id CAKFQuwbvans2FfhO=-oOk73wJNETWh8mV0ZODc818kHCzQGT_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: rounding up time value less than its unit.  (Gregory Smith <gregsmithpgsql@gmail.com>)
Список pgsql-hackers
On Thu, Sep 25, 2014 at 12:11 AM, Gregory Smith <gregsmithpgsql@gmail.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: proposal: rounding up time value less than its unit.
Следующее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: a fast bloat measurement tool (was Re: Measuring relation free space)