Re: disabling log_rotation_age feature.

On Thu, Jun 12, 2014 at 1:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

David Johnston <david.g.johnston@gmail.com> writes:
> On Thursday, June 12, 2014, Tom Lane <tgl@sss.pgh.pa.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.