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

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

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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: LIMIT for UPDATE and DELETE
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: BRIN indexes - TRAP: BadArgument