Thread: Re: [COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Cc'ing -hackers.

Andres Freund wrote:
> On 2015-09-24 10:37:33 -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:

> > Should this patch not have also touched the per-table limits in
> > reloptions.c?
> 
> Hm. I guess that'd make sense. It's not really related to the goal of
> making it realistic to test multixact/clog truncation, but it's less
> confusing if consistent.

Yeah, agreed.

> > and I found places in create_table.sgml that claim these variables can be
> > set to zero.  You didn't break that with this patch, but it's still wrong.
> 
> Seems to have been "broken" back in 834a6da4f7 - the old table based
> approach doesn't seem to have imposed lower limits. I'm not really sure
> whether making the limits consistent and updating the docs or removing
> them alltogether is the better approach.

I'm surprised the error has survived this long.  Without checking I
can't say what's the best solution either, but I would opt for
documenting the limits we have -- if we want to change them back to 0 I
say that merits its own discussion.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2015-09-24 12:39:54 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2015-09-24 10:37:33 -0400, Tom Lane wrote:
> > > Andres Freund <andres@anarazel.de> writes:
> 
> > > Should this patch not have also touched the per-table limits in
> > > reloptions.c?
> > 
> > Hm. I guess that'd make sense. It's not really related to the goal of
> > making it realistic to test multixact/clog truncation, but it's less
> > confusing if consistent.
> 
> Yeah, agreed.

Pushed. I actually noticed that the lower limit reloption
multixact_freeze_max_age in reloptions was wrong independent of recent
commits.

> > > and I found places in create_table.sgml that claim these variables can be
> > > set to zero.  You didn't break that with this patch, but it's still wrong.
> > 
> > Seems to have been "broken" back in 834a6da4f7 - the old table based
> > approach doesn't seem to have imposed lower limits. I'm not really sure
> > whether making the limits consistent and updating the docs or removing
> > them alltogether is the better approach.
> 
> I'm surprised the error has survived this long.  Without checking I
> can't say what's the best solution either, but I would opt for
> documenting the limits we have -- if we want to change them back to 0 I
> say that merits its own discussion.

How about simply removing that sentence? I.e. something like     <literal>autovacuum_freeze_max_age</> larger than the
system-widesetting
 
-     (it can only be set smaller). Note that while you can set
-     <literal>autovacuum_freeze_max_age</> very small, or even zero, this is
-     usually unwise since it will force frequent vacuuming.
+     (it can only be set smaller).     </para>

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2015-09-24 12:39:54 -0300, Alvaro Herrera wrote:
>> I'm surprised the error has survived this long.  Without checking I
>> can't say what's the best solution either, but I would opt for
>> documenting the limits we have -- if we want to change them back to 0 I
>> say that merits its own discussion.

> How about simply removing that sentence? I.e. something like
>       <literal>autovacuum_freeze_max_age</> larger than the system-wide setting
> -     (it can only be set smaller). Note that while you can set
> -     <literal>autovacuum_freeze_max_age</> very small, or even zero, this is
> -     usually unwise since it will force frequent vacuuming.
> +     (it can only be set smaller).
>       </para>

How about "Setting autovacuum_freeze_max_age to very small values
is unwise since it will force frequent vacuuming."
        regards, tom lane

On 2015-10-05 09:39:58 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > How about simply removing that sentence? I.e. something like
> >       <literal>autovacuum_freeze_max_age</> larger than the system-wide setting
> > -     (it can only be set smaller). Note that while you can set
> > -     <literal>autovacuum_freeze_max_age</> very small, or even zero, this is
> > -     usually unwise since it will force frequent vacuuming.
> > +     (it can only be set smaller).
> >       </para>
> 
> How about "Setting autovacuum_freeze_max_age to very small values
> is unwise since it will force frequent vacuuming."

Well, you still can't really set it to a very small value - the lower
limits are still 100k/10k for xids/mxids. To me that sentence mostly
made sense with the old logic where no lower limits existed.

Andres

Andres Freund <andres@anarazel.de> writes:
> On 2015-10-05 09:39:58 -0400, Tom Lane wrote:
>> How about "Setting autovacuum_freeze_max_age to very small values
>> is unwise since it will force frequent vacuuming."

> Well, you still can't really set it to a very small value - the lower
> limits are still 100k/10k for xids/mxids. To me that sentence mostly
> made sense with the old logic where no lower limits existed.

Good point.  Agreed, let's just flush it.
        regards, tom lane