Subject: disabling log_rotation_age feature.

From: Tomonari Katsumata <[email-masked]>
Date: Thu, 12 Jun 2014 13:43:36 +0900

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-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

---

From: David G Johnston <[email-masked]>
Date: Wed, 11 Jun 2014 23:28:21 -0700 (PDT)

Tomonari Katsumata-2 wrote
> However, the feature would be disabled if we set it less than one minute.

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.

---

From: David G Johnston <[email-masked]>
Date: Wed, 11 Jun 2014 23:35:25 -0700 (PDT)

David G Johnston wrote
> (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.

---

From: Fujii Masao <[email-masked]>
Date: Thu, 12 Jun 2014 21:26:09 +0900

> 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

---

From: Tom Lane <[email-masked]>
Date: Thu, 12 Jun 2014 10:41:35 -0400

> 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

---

From: David G Johnston <[email-masked]>
Date: Thu, 12 Jun 2014 08:35:16 -0700 (PDT)

On Thu, Jun 12, 2014 at 10:42 AM, Tom Lane-2 [via PostgreSQL] <
[email-masked]> wrote:

> Fujii Masao <[hidden email]
> <http://user/SendEmail.jtp?type=node&node=5807014&i=0>> writes:
> > <[hidden email] <http://user/SendEmail.jtp?type=node&node=5807014&i=1>>
> wrote:
​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-masked]

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.

---

From: Tom Lane <[email-masked]>
Date: Thu, 12 Jun 2014 12:00:00 -0400

> ​I think documenting the behavior better,

I don't.  If you have to explain it, it probably needs improvement.

> features on that are currently off it doesn't seem to be beneficial enough

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

---

From: David Johnston <[email-masked]>
Date: Thu, 12 Jun 2014 12:16:07 -0400

On Thursday, June 12, 2014, Tom Lane <[email-masked]> wrote:

> David G Johnston <[email-masked] <javascript:;>> writes:
> > [email-masked] <javascript:;>> wrote:

No argument with the philosophy.

> 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.

---

From: Tom Lane <[email-masked]>
Date: Thu, 12 Jun 2014 13:25:34 -0400

> 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

---

From: David Johnston <[email-masked]>
Date: Thu, 12 Jun 2014 14:20:48 -0400

forgot the list...

On Thu, Jun 12, 2014 at 2:05 PM, David Johnston <[email-masked]>
wrote:

> On Thu, Jun 12, 2014 at 1:25 PM, Tom Lane <[email-masked]> wrote:
>
>> 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
>> 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
> 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.
>
>
> ​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.
>
>

---

From: Tomonari Katsumata <[email-masked]>
Date: Fri, 13 Jun 2014 12:11:20 +0900

Hi,

Thank you for many comments.

I've not thought about another parameters...
Sorry for my thoughtless.

 >> 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