Make vacuum_defer_cleanup_age be PGC_SIGHUP level, since it's not sensible

to have different values in different processes of the primary server.
Also put it into the "Streaming Replication" GUC category; it doesn't belong
in "Standby Servers" because you use it on the master not the standby.
In passing also correct guc.c's idea of wal_keep_segments' category.
This commit is contained in:
Tom Lane 2010-07-03 21:23:58 +00:00
parent e76c1a0f4d
commit aceedd88f6
4 changed files with 41 additions and 31 deletions

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.289 2010/07/03 20:43:57 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.290 2010/07/03 21:23:58 tgl Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -1914,6 +1914,31 @@ SET ENABLE_SEQSCAN TO OFF;
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-vacuum-defer-cleanup-age" xreflabel="vacuum_defer_cleanup_age">
<term><varname>vacuum_defer_cleanup_age</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>vacuum_defer_cleanup_age</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
Specifies the number of transactions by which <command>VACUUM</> and
<acronym>HOT</> updates will defer cleanup of dead row versions. The
default is zero transactions, meaning that dead row versions can be
removed as soon as possible, that is, as soon as they are no longer
visible to any open transaction. You may wish to set this to a
non-zero value on a primary server that is supporting hot standby
servers, as described in <xref linkend="hot-standby">. This allows
more time for queries on the standby to complete without incurring
conflicts due to early cleanup of rows. However, since the value
is measured in terms of number of write transactions occurring on the
primary server, it is difficult to predict just how much additional
grace time will be made available to standby queries.
This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
@ -2004,29 +2029,6 @@ SET ENABLE_SEQSCAN TO OFF;
</listitem>
</varlistentry>
<varlistentry id="guc-vacuum-defer-cleanup-age" xreflabel="vacuum_defer_cleanup_age">
<term><varname>vacuum_defer_cleanup_age</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>vacuum_defer_cleanup_age</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
Specifies the number of transactions by which <command>VACUUM</> and
<acronym>HOT</> updates will defer cleanup of dead row versions. The
default is 0 transactions, meaning that dead row versions will be
removed as soon as possible. You may wish to set this to a non-zero
value when planning or maintaining a Hot Standby connection, as
described in <xref linkend="hot-standby">. The recommended value is
<literal>0</> unless you have clear reason to increase it. The purpose
of the parameter is to allow the user to specify an approximate time
delay before cleanup occurs. However, it should be noted that there is
no direct link with any specific time delay and so the results will be
application and installation specific, as well as variable over time,
depending upon the transaction rate (of writes only).
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>

View File

@ -37,7 +37,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/storage/ipc/procarray.c,v 1.70 2010/05/14 07:11:49 sriggs Exp $
* $PostgreSQL: pgsql/src/backend/storage/ipc/procarray.c,v 1.71 2010/07/03 21:23:58 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -1117,7 +1117,15 @@ GetOldestXmin(bool allDbs, bool ignoreVacuum)
LWLockRelease(ProcArrayLock);
/*
* Compute the cutoff XID, being careful not to generate a "permanent" XID
* Compute the cutoff XID, being careful not to generate a "permanent" XID.
*
* vacuum_defer_cleanup_age provides some additional "slop" for the
* benefit of hot standby queries on slave servers. This is quick and
* dirty, and perhaps not all that useful unless the master has a
* predictable transaction rate, but it's what we've got. Note that
* we are assuming vacuum_defer_cleanup_age isn't large enough to cause
* wraparound --- so guc.c should limit it to no more than the xidStopLimit
* threshold in varsup.c.
*/
result -= vacuum_defer_cleanup_age;
if (!TransactionIdIsNormal(result))

View File

@ -10,7 +10,7 @@
* Written by Peter Eisentraut <peter_e@gmx.net>.
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.558 2010/07/03 20:43:58 tgl Exp $
* $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.559 2010/07/03 21:23:58 tgl Exp $
*
*--------------------------------------------------------------------
*/
@ -1631,8 +1631,8 @@ static struct config_int ConfigureNamesInt[] =
},
{
{"vacuum_defer_cleanup_age", PGC_USERSET, WAL_STANDBY_SERVERS,
gettext_noop("Age by which VACUUM and HOT cleanup should be deferred, if any."),
{"vacuum_defer_cleanup_age", PGC_SIGHUP, WAL_REPLICATION,
gettext_noop("Number of transactions by which VACUUM and HOT cleanup should be deferred, if any."),
NULL
},
&vacuum_defer_cleanup_age,
@ -1675,7 +1675,7 @@ static struct config_int ConfigureNamesInt[] =
},
{
{"wal_keep_segments", PGC_SIGHUP, WAL_CHECKPOINTS,
{"wal_keep_segments", PGC_SIGHUP, WAL_REPLICATION,
gettext_noop("Sets the number of WAL files held for standby servers."),
NULL
},

View File

@ -188,6 +188,7 @@
#max_wal_senders = 0 # max number of walsender processes
#wal_sender_delay = 200ms # walsender cycle time, 1-10000 milliseconds
#wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables
#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
# - Standby Servers -
@ -198,7 +199,6 @@
#max_standby_streaming_delay = 30s # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
#vacuum_defer_cleanup_age = 0 # number of transactions by which cleanup is deferred
#------------------------------------------------------------------------------