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

On Tue, Sep 23, 2014 at 10:11 PM, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>
wrote:

> On 9/23/14, 1:21 AM, David Johnston wrote:
>
>> This patch should fix the round-to-zero issue. If someone wants to get
>> rid of zero as a special case let them supply a separate patch for that
>> "improvement".
>>
>
> I am going to wander into this fresh after just reading everything once
> (but with more than a little practice with real-world GUC mucking) and say
> that, no, it should not even do that. The original complaint here is real
> and can be straightforward to fix, but I don't like any of the proposals so
> far.
>
> My suggestion: fix the one really bad one in 9.5 with an adjustment to
> the units of log_rotation_age. That's a small commit that should thank
> Tomonari Katsumata for discovering the issue and even suggesting a fix
> (that we don't use) and a release note; sample draft below. Stop there.
>
>
​+1​

I'm not convinced "minute" is wrong but it does imply a level of
user-friendliness (or over-parenting) that we can do away with.

>
> We could just change the units for log_rotation_age to seconds, then let
> the person who asks for a 10s rotation time suffer for that decision only
> with many log files. The person who instead chooses 10ms may find log
> rotation disabled altogether because that rounds to zero, but now we are
> not talking about surprises on something that seems sane--that's a fully
> unreasonable user request.
>

​Given the following why not just pick "ms" for log_rotation_age now?
​

>
> Following that style of fix all the way through to the sort of release
> notes needed would give something like this:
>
> log_rotation_age is now set in units of seconds instead of minutes.
> Earlier installations of PostgreSQL that set this value directly, to a
> value in minutes, should change that setting to use a time unit before
> migrating to this version.
>
>
? are there any special considerations for people using pg_dump vs. those
using pg_upgrade?​

> If I were feeling ambitious about breaking configurations with a long-term
> eye toward improvement, I'd be perfectly happy converting everything on
> this list to ms. We live in 64 bit integer land now; who cares if the
> numbers are bigger?

> Then the rounding issues only impact sub-millisecond values, making all
> them squarely in nonsense setting land. Users will be pushed very clearly
> to always use time units in their postgresql.conf files instead of guessing
> whether something is set in ms vs. seconds. Seeing the reaction to a units
> change on log_rotation_age might be a useful test for how that sort of
> change plays out in the real world.

​If we are going to go that far why not simply modify the GUC input routine
to require unit-values on these particular parameters? Direct manipulation
of pg_settings probably would need some attention but everything else could
reject integers and non-unit-specifying text. Allow the same input routine
to accept the constants "on|off|default" and convert them internally into
whatever the given GUC requires and you get the UI benefits without mucking
around with the implementation details. Modify pg_settings accordingly to
hide those now-irrelevant pieces. For UPDATE a trigger can be used to
enforce the text-only input requirement.

As long as we do not make microsecond "µs" a valid time-unit it is
impossible currently to directly specify a fraction of a millisecond.

David J.
​