Re: disabling log_rotation_age feature.

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. That is, if you write "10s" for
a variable that's stored in minutes, what should you get? I doubt that
"an error" is the best answer here --- 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. 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.

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.

regards, tom lane