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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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 (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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 (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
On Thu, Jun 12, 2014 at 10:42 AM, Tom Lane-2 [via PostgreSQL] <
ml-node+s1045698n5807014h58@n5.nabble.com> 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?
/messages/by-id/CAKFQuwbbOZRqmnx-XRyd+viT+MCAH6TVc0yn1aJtG5MdSNAWpA@mail.gmail.com
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.
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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
On Thursday, June 12, 2014, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David G Johnston <david.g.johnston@gmail.com <javascript:;>> writes:
On Thu, Jun 12, 2014 at 10:42 AM, Tom Lane-2 [via PostgreSQL] <
ml-node+s1045698n5807014h58@n5.nabble.com <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 beneficialenough
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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
forgot the list...
On Thu, Jun 12, 2014 at 2:05 PM, David Johnston <david.g.johnston@gmail.com>
wrote:
Show quoted text
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 -> 1That 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 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.
Import Notes
Reply to msg id not found: CAKFQuwae62FLDy2N7KEt5RHyCqakyN0mp0q_qmJ=kSuouodb7Q@mail.gmail.com
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 (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs