On Tue, Sep 23, 2014 at 10:11 PM, Gregory Smith <gregsmithpg...@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.
