Re: disabling log_rotation_age feature.

forgot the list...

On Thu, Jun 12, 2014 at 2:05 PM, David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Thu, Jun 12, 2014 at 1:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>> > On Thursday, June 12, 2014, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> >> I don't think that argument holds water either. We routinely make
>> >> changes that break old postgresql.conf files. Not in minor updates
>> >> of course, but none of this is material for back-patching.
>>
>> > Then I'd pick throwing an error if a floating point value is assigned
>> to a
>> > parameter that is defined to accept integer. I'd rather actually break
>> the
>> > file and not silently redefine its contents.
>>
>> The case that was under discussion here had nothing to do with float vs
>> integer: it was about rounding a time-interval value to the precision
>> chosen for the underlying variable.
>
>
> ​I get that: if I request "30s" I get a result of 0.5 - which is then
> truncated​ to zero; "90s" = 1.5 -> 1
>
> That is, if you write "10s" for
>> a variable that's stored in minutes, what should you get?
>
>
> ​0.166667
>
>
>> I doubt that
>> "an error" is the best answer here
>
>
> ​If we cannot honor the exact value requested telling that to the user is
> definitely a valid outcome​
>
>
>> --- one of the purposes of the units
>> system for GUCs was to avoid people having to pay close attention to
>> exactly what the measurement unit of each GUC is.
>
>
> ​And if their desired value falls into the expected range of allowed
> values ​then they can remain oblivious. But if they want to do something
> that the system is incapable of supporting forcing them to explicitly chose
> a different value is just as valid a decision as picking one for them.
>
> ​Restricting that to scaling up - which is what happens in reality anyway
> - means that at least whatever the user tells the system is either what
> they get or they are told their request is invalid.
>
> The likelihood of someone requesting "120s" when they desire "2m" is
> unlikely - I would think that most typically they would be requesting a
> number of, in this case, seconds that are less than the default unit​, 1
> minute in this case.
>
> If it only errors when the final result is zero I would not be overly
> opposed to situations like "90s" rounding to "2m" instead of "1m".
>
>
>> So the realistic
>> answers are "zero minutes" or "1 minute"; and if "zero minutes" is a
>> special case then there's considerable merit in making the value go to
>> "1 minute" instead.
>>
>
> Another supporting argument is that the risk profile for anyone depending
> on a non-explicit zero to obtain zero behavior ​is small - if they changed
> from default and were checking to make sure the final result matched their
> expectation they would see the relevant difference. The OP complaint
> indeed is "I thought I enabled this but it didn't work".
>
> I am somewhat concerned about, say "100m" rounding to 2 hours instead of 1
> hour. The minute/second rounding is fairly small but for larger unit-pairs
> the amount of delta before and after can be considerable. But there may be
> few, if any, parameters that could be so affected so probably a moot
> concern.
>
>
>> Note that right at the moment the behavior is "round down", ie you get
>> zero not 1 minute even if you wrote "59s". I claim that's definitely
>> surprising.
>>
>>
> ​As is rounding "70s" up to "2m"
>
> In both cases since we are taking invalid data and substituting valid data
> we have to document what is being done. Its just the probability of
> someone realizing and caring about what we are doing is smaller if we use
> ceiling instead of floor.
>
> While I am generally in favor of requiring explicitness there is minimal
> downside risk in leaving "implicit casting" of the data in this context.
> Given that conclusion, making the change to ceiling from floor makes sense
> - making it possible to only achieve zero explicitly is worthwhile. For all
> non-zero situations the direction of rounding is largely immaterial if you
> accept that rounding has value.
>
> David J.
>
>