public inbox for [email protected]
help / color / mirror / Atom feeddisabling log_rotation_age feature.
11+ messages / 5 participants
[nested] [flat]
* disabling log_rotation_age feature.
@ 2014-06-12 04:43 Tomonari Katsumata <[email protected]>
0 siblings, 2 replies; 11+ messages in thread
From: Tomonari Katsumata @ 2014-06-12 04:43 UTC (permalink / raw)
To: pgsql-docs
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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 06:28 David G Johnston <[email protected]>
parent: Tomonari Katsumata <[email protected]>
1 sibling, 1 reply; 11+ messages in thread
From: David G Johnston @ 2014-06-12 06:28 UTC (permalink / raw)
To: pgsql-docs
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.
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 06:35 David G Johnston <[email protected]>
parent: David G Johnston <[email protected]>
0 siblings, 0 replies; 11+ messages in thread
From: David G Johnston @ 2014-06-12 06:35 UTC (permalink / raw)
To: pgsql-docs
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.
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 12:26 Fujii Masao <[email protected]>
parent: Tomonari Katsumata <[email protected]>
1 sibling, 1 reply; 11+ messages in thread
From: Fujii Masao @ 2014-06-12 12:26 UTC (permalink / raw)
To: Tomonari Katsumata <[email protected]>; +Cc: pgsql-docs
On Thu, Jun 12, 2014 at 1:43 PM, Tomonari Katsumata
<[email protected]> 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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 14:41 Tom Lane <[email protected]>
parent: Fujii Masao <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2014-06-12 14:41 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Tomonari Katsumata <[email protected]>; pgsql-docs
Fujii Masao <[email protected]> writes:
> On Thu, Jun 12, 2014 at 1:43 PM, Tomonari Katsumata
> <[email protected]> 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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 15:35 David G Johnston <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: David G Johnston @ 2014-06-12 15:35 UTC (permalink / raw)
To: pgsql-docs
On Thu, Jun 12, 2014 at 10:42 AM, Tom Lane-2 [via PostgreSQL] <
[email protected]> wrote:
> Fujii Masao <[hidden email]
> <http://user/SendEmail.jtp?type=node&node=5807014&i=0>; writes:
> > On Thu, Jun 12, 2014 at 1:43 PM, Tomonari Katsumata
> > <[hidden email] <http://user/SendEmail.jtp?type=node&node=5807014&i=1>;
> 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.
>
>
>
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?
http://www.postgresql.org/message-id/[email protected]....
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: http://postgresql.1045698.n5.nabble.com/disabling-log-rotation-age-feature-tp5806936p5807032.html
Sent from the PostgreSQL - docs mailing list archive at Nabble.com.
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 16:00 Tom Lane <[email protected]>
parent: David G Johnston <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2014-06-12 16:00 UTC (permalink / raw)
To: David G Johnston <[email protected]>; +Cc: pgsql-docs
David G Johnston <[email protected]> writes:
> On Thu, Jun 12, 2014 at 10:42 AM, Tom Lane-2 [via PostgreSQL] <
> [email protected]> 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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 16:16 David Johnston <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: David Johnston @ 2014-06-12 16:16 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-docs
On Thursday, June 12, 2014, Tom Lane <[email protected]> wrote:
> David G Johnston <[email protected] <javascript:;>> writes:
> > On Thu, Jun 12, 2014 at 10:42 AM, Tom Lane-2 [via PostgreSQL] <
> > [email protected] <javascript:;>> 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.
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 17:25 Tom Lane <[email protected]>
parent: David Johnston <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2014-06-12 17:25 UTC (permalink / raw)
To: David Johnston <[email protected]>; +Cc: pgsql-docs
David Johnston <[email protected]> writes:
> On Thursday, June 12, 2014, Tom Lane <[email protected]> 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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-12 18:20 David Johnston <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: David Johnston @ 2014-06-12 18:20 UTC (permalink / raw)
To: pgsql-docs
forgot the list...
On Thu, Jun 12, 2014 at 2:05 PM, David Johnston <[email protected]>
wrote:
> On Thu, Jun 12, 2014 at 1:25 PM, Tom Lane <[email protected]> wrote:
>
>> David Johnston <[email protected]> writes:
>> > On Thursday, June 12, 2014, Tom Lane <[email protected]> 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.
>
>
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: disabling log_rotation_age feature.
@ 2014-06-13 03:11 Tomonari Katsumata <[email protected]>
parent: David Johnston <[email protected]>
0 siblings, 0 replies; 11+ messages in thread
From: Tomonari Katsumata @ 2014-06-13 03:11 UTC (permalink / raw)
To: pgsql-docs
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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2014-06-13 03:11 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2014-06-12 04:43 disabling log_rotation_age feature. Tomonari Katsumata <[email protected]>
2014-06-12 06:28 ` David G Johnston <[email protected]>
2014-06-12 06:35 ` David G Johnston <[email protected]>
2014-06-12 12:26 ` Fujii Masao <[email protected]>
2014-06-12 14:41 ` Tom Lane <[email protected]>
2014-06-12 15:35 ` David G Johnston <[email protected]>
2014-06-12 16:00 ` Tom Lane <[email protected]>
2014-06-12 16:16 ` David Johnston <[email protected]>
2014-06-12 17:25 ` Tom Lane <[email protected]>
2014-06-12 18:20 ` David Johnston <[email protected]>
2014-06-13 03:11 ` Tomonari Katsumata <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox