1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00

Avoid passing zero as a value for vacuum_cost_limit, because it's not a valid

value for the vacuum code.  Instead, make zero signify getting the value from a
higher level configuration facility, just like -1 in the original coding.  We
still document that -1 is the value that disables the feature, to avoid
confusing the user unnecessarily.

Reported by Galy Lee in <200705310914.l4V9E6JA094603@wwwmaster.postgresql.org>;
per subsequent discussion.
This commit is contained in:
Alvaro Herrera
2007-06-08 21:09:49 +00:00
parent 4213e5f0db
commit 2b438c12cc
2 changed files with 13 additions and 7 deletions

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.153 2007/06/05 21:31:03 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.154 2007/06/08 21:09:49 alvherre Exp $ -->
<!--
Documentation of the system catalogs, directed toward PostgreSQL developers
-->
@ -1339,7 +1339,7 @@
be used for this particular value. Observe that the
<structfield>vac_cost_delay</> variable inherits its default value from the
<xref linkend="guc-autovacuum-vacuum-cost-delay"> configuration parameter,
or from <varname>vacuum_cost_delay</> if the former is set to a negative
or from <xref linkend="guc-vacuum-cost-delay"> if the former is set to a negative
value. The same applies to <structfield>vac_cost_limit</>.
Also, autovacuum will ignore attempts to set a per-table
<structfield>freeze_max_age</> larger than the system-wide setting (it can only be set