pgsql: Lower *_freeze_max_age minimum values.
Lower *_freeze_max_age minimum values.
The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 10000000
multixacts can contain a lot of members.
Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.
While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.
Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=OztbDGGrovkkEzQ@mail.gmail.com
Backpatch: back to 9.0 (in parts)
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/020235a5754be6ba1f0d240b4c86c642e1a62d70
Modified Files
--------------
src/backend/utils/misc/guc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Andres Freund <andres@anarazel.de> writes:
Lower *_freeze_max_age minimum values.
Should this patch not have also touched the per-table limits in
reloptions.c?
Also, I went looking for documentation about the minimum allowed values,
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.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 2015-09-24 10:37:33 -0400, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
Lower *_freeze_max_age minimum values.
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.
Also, I went looking for documentation about the minimum allowed
values,
I seached for references and was surprised we don't document the limits
anywhere....
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.
Greetings,
Andres Freund
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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-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>Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers