Thread: disabling log_rotation_age feature.
Hi,
I'm reading about log_rotation_age.
And I noticed that the setting for disabling the feature is not clear.
The document tells us to set it to ZERO if we want to disable the feature.
However, the feature would be disabled if we set it less than one minute.
[Example]
*******************************************
$ grep log_rotation_age ${PGDATA}/postgresql.conf
#log_rotation_age = 1d # Automatic rotation of logfiles will
log_rotation_age = 10s # Automatic rotation of logfiles will
$ psql postgres
psql (9.5devel)
Type "help" for help.
postgres=# show log_rotation_age ;
log_rotation_age
------------------
0
(1 row)
*******************************************
I think this fact should be written on document for users.
[Fix Example]
*********
After this many minutes have elapsed, a new log file will
- be created. Set to zero to disable time-based creation of
+ be created. Set to zero or less than one minute to disable time-based
new log files.
*********
regards,
-----------------
Tomonari Katsumata
Tomonari Katsumata-2 wrote
> Hi,
>
> I'm reading about log_rotation_age.
> And I noticed that the setting for disabling the feature is not clear.
>
>
> The document tells us to set it to ZERO if we want to disable the feature.
> However, the feature would be disabled if we set it less than one minute.
>
> [Example]
> *******************************************
> $ grep log_rotation_age ${PGDATA}/postgresql.conf
> #log_rotation_age = 1d # Automatic rotation of logfiles will
> log_rotation_age = 10s # Automatic rotation of logfiles will
>
> $ psql postgres
> psql (9.5devel)
> Type "help" for help.
>
> postgres=# show log_rotation_age ;
> log_rotation_age
> ------------------
> 0
> (1 row)
> *******************************************
>
> I think this fact should be written on document for users.
>
> [Fix Example]
> *********
> After this many minutes have elapsed, a new log file will
> - be created. Set to zero to disable time-based creation of
> + be created. Set to zero or less than one minute to disable time-based
> new log files.
> *********
I suggest documenting, if correct, that maximum resolution is minutes
(rounding down) and thus any sub-1-minute value will be interpreted as zero
and disable the feature.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/disabling-log-rotation-age-feature-tp5806936p5806947.html
Sent from the PostgreSQL - docs mailing list archive at Nabble.com.
David G Johnston wrote
>
> Tomonari Katsumata-2 wrote
>> Hi,
>>
>> I'm reading about log_rotation_age.
>> And I noticed that the setting for disabling the feature is not clear.
>>
>>
>> The document tells us to set it to ZERO if we want to disable the
>> feature.
>> However, the feature would be disabled if we set it less than one minute.
>>
>> [Example]
>> *******************************************
>> $ grep log_rotation_age ${PGDATA}/postgresql.conf
>> #log_rotation_age = 1d # Automatic rotation of logfiles will
>> log_rotation_age = 10s # Automatic rotation of logfiles will
>>
>> $ psql postgres
>> psql (9.5devel)
>> Type "help" for help.
>>
>> postgres=# show log_rotation_age ;
>> log_rotation_age
>> ------------------
>> 0
>> (1 row)
>> *******************************************
>>
>> I think this fact should be written on document for users.
>>
>> [Fix Example]
>> *********
>> After this many minutes have elapsed, a new log file will
>> - be created. Set to zero to disable time-based creation of
>> + be created. Set to zero or less than one minute to disable time-based
>> new log files.
>> *********
> I suggest documenting, if correct, that maximum resolution is minutes
> (rounding down) and thus any sub-1-minute value will be interpreted as
> zero and disable the feature.
>
> David J.
Note that given the description and the fact only integer is supported the
above is already implied today. I would think specifying a seconds should
result in an error since doing so requires a floating point value.
Is it documented (if true) that any floating point number given to an
integer typed parameter is truncated? Or does the time form with units have
some special behavior?
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/disabling-log-rotation-age-feature-tp5806936p5806948.html
Sent from the PostgreSQL - docs mailing list archive at Nabble.com.
On Thu, Jun 12, 2014 at 1:43 PM, Tomonari Katsumata <katsumata.tomonari@po.ntts.co.jp> wrote: > Hi, > > I'm reading about log_rotation_age. > And I noticed that the setting for disabling the feature is not clear. > > > The document tells us to set it to ZERO if we want to disable the feature. > However, the feature would be disabled if we set it less than one minute. That's because log_rotation_age expects the setting value in minutes. This is not a problem only for log_rotation_age. When setting the parameter which expects the value in seconds to less than one second, the setting value is implicitly reset to the default. For example, postgres=# SHOW tcp_keepalives_idle ; tcp_keepalives_idle --------------------- 7200 (1 row) postgres=# SET tcp_keepalives_idle TO '10ms'; SET postgres=# SHOW tcp_keepalives_idle ; tcp_keepalives_idle --------------------- 7200 (1 row) postgres=# SET tcp_keepalives_idle TO '1024ms'; SET postgres=# SHOW tcp_keepalives_idle ; tcp_keepalives_idle --------------------- 1 (1 row) Regards, -- Fujii Masao
Fujii Masao <masao.fujii@gmail.com> writes:
> On Thu, Jun 12, 2014 at 1:43 PM, Tomonari Katsumata
> <katsumata.tomonari@po.ntts.co.jp> wrote:
>> The document tells us to set it to ZERO if we want to disable the feature.
>> However, the feature would be disabled if we set it less than one minute.
> That's because log_rotation_age expects the setting value in minutes.
> This is not a problem only for log_rotation_age. When setting the parameter
> which expects the value in seconds to less than one second, the setting value
> is implicitly reset to the default.
It's not "reset to default", it's set to zero due to rounding the fraction
down. Some GUCs interpret zero specially, some don't.
I wonder if we should round fractions up instead of down in that logic?
It might be less surprising for those GUCs where zero is special, and
it seems like about a wash for most others.
regards, tom lane
Fujii Masao <[hidden email]> writes:
> On Thu, Jun 12, 2014 at 1:43 PM, Tomonari Katsumata
> <[hidden email]> wrote:>> The document tells us to set it to ZERO if we want to disable the feature.It's not "reset to default", it's set to zero due to rounding the fraction
>> However, the feature would be disabled if we set it less than one minute.
> That's because log_rotation_age expects the setting value in minutes.
> This is not a problem only for log_rotation_age. When setting the parameter
> which expects the value in seconds to less than one second, the setting value
> is implicitly reset to the default.
down. Some GUCs interpret zero specially, some don't.
I wonder if we should round fractions up instead of down in that logic?
It might be less surprising for those GUCs where zero is special, and
it seems like about a wash for most others.
I think documenting the behavior better, which I would do as part of the larger patch I'm working on here:
[9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
would be sufficient.
Green field maybe I'd say yes but given that the new behavior could turn features on that are currently off it doesn't seem to be beneficial enough to warrant changing.
David J.
View this message in context: Re: disabling log_rotation_age feature.
Sent from the PostgreSQL - docs mailing list archive at Nabble.com.
David G Johnston <david.g.johnston@gmail.com> writes:
> On Thu, Jun 12, 2014 at 10:42 AM, Tom Lane-2 [via PostgreSQL] <
> ml-node+s1045698n5807014h58@n5.nabble.com> wrote:
>> I wonder if we should round fractions up instead of down in that logic?
>> It might be less surprising for those GUCs where zero is special, and
>> it seems like about a wash for most others.
> I think documenting the behavior better,
I don't. If you have to explain it, it probably needs improvement.
> Green field maybe I'd say yes but given that the new behavior could turn
> features on that are currently off it doesn't seem to be beneficial enough
> to warrant changing.
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.
regards, tom lane
On Thursday, June 12, 2014, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David G Johnston <david.g.johnston@gmail.com> writes:
> On Thu, Jun 12, 2014 at 10:42 AM, Tom Lane-2 [via PostgreSQL] <
> ml-node+s1045698n5807014h58@n5.nabble.com> wrote:
>> I wonder if we should round fractions up instead of down in that logic?
>> It might be less surprising for those GUCs where zero is special, and
>> it seems like about a wash for most others.
> I think documenting the behavior better,
I don't. If you have to explain it, it probably needs improvement.
No argument with the philosophy.
> Green field maybe I'd say yes but given that the new behavior could turn
> features on that are currently off it doesn't seem to be beneficial enough
> to warrant changing.
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.
David J.
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. 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
forgot the list...
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 makeThe case that was under discussion here had nothing to do with float vs
>> 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.
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 -> 1That is, if you write "10s" for
a variable that's stored in minutes, what should you get?0.166667I doubt that
"an error" is the best answer hereIf 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.
Hi, Thank you for many comments. I've not thought about another parameters... Sorry for my thoughtless. >> 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. > Now, I think it's better to round-up the value that is less than its unit. Since I could avoid unexpected setting(round-down to zero) with rounding it up. And document this on "18.1.1. Parameter Names and Values". regards, ---------------- Tomonari Katsumata