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

Hey Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tomonari Katsumata (t.katsumata1122@gmail.com) wrote:
> >> I'm thinking about a method which users get quick awareness it.
> >> Now, it's okay not to change current behavior except non-zero value yields
> >> a zero. A zero rounded down from non-zero gets an error.
>
> > In general, I'm a fan of this change and will move forward with it,
> > with changes for the above, unless folks object.  Based on the thread so
> > far, this sounds like the right solution and it'd be great to get this
> > simple change done to help move the CF along.
>
> Hm, I object to a patch that behaves as stated above.  I'm okay with
> silently rounding *up* to the lowest possible nonzero value, eg rounding
> up 7kB to 8kB if the variable's unit is 8kB.  But if we throw an error for
> 7kB and not 8kB, then we are exposing the unit size in a way that the user
> can't ignore.  That seems to me to be antithetical to the entire design
> rationale for GUC units.  More, it doesn't fix the original complaint here,
> which is that the user would be surprised if he specifies 7kB and gets
> some special behavior instead because it's "too close to zero but not
> exactly zero".  7kB should act as though it's not zero.  If the difference
> between 7kB and 8kB is actually user-meaningful, then we chose too coarse
> a unit for the particular GUC, which is not something that a rounding rule
> can paper over.  But the difference between zero and not-zero is
> meaningful regardless of unit choices.

I agree that the difference between 7kB and 8kB shouldn't be meaningful,
but that it can be if it means we end up at zero.  Having different
rounding rules at "near-zero" than in other cases doesn't strike me as
great either though, which is why I thought the error-if-rounded-to-zero
made sense.  As for the user, I'd aruge that they haven't understood the
GUC if they're setting the value down to something which rounds to zero
and an error (yes, even one in the logs that we know few enough folks
read) would be better than where we are currently.

> This argument doesn't say anything much about which way to round for
> values that are fractional but larger than the unit size.  I'd probably
> prefer a "round away from zero" behavior since that seems to be the most
> consistent rule if we want to avoid silently creating zero values; but
> I could be talked into something else.

PeterE argued that rounding away from zero didn't make sense either
(53F6501B.3090201@gmx.net).  I feel like we're getting trapped by
examples.

Here's another proposal- how about we support a 'minimum-if-not-zero'
option for GUCs more generally, and then throw an error if the user sets
the value to a value below that minimum unless they explicitly use zero
(to indicate whatever the special meaning of zero for that GUC is)?
It'd be a larger change, certainly, but I feel like that combined with
the current behavior would address this and possibly other issues
(setting to a value which is low enough to be accepted, but too low to
allow the system to function properly..).
Thanks!
    Stephen