Обсуждение: 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(-)

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

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