diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/config.sgml | 35 | ||||
| -rw-r--r-- | doc/src/sgml/high-availability.sgml | 28 |
2 files changed, 6 insertions, 57 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 091a79d4f36..b56f073a918 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -4614,41 +4614,6 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class=" </listitem> </varlistentry> - <varlistentry id="guc-vacuum-defer-cleanup-age" xreflabel="vacuum_defer_cleanup_age"> - <term><varname>vacuum_defer_cleanup_age</varname> (<type>integer</type>) - <indexterm> - <primary><varname>vacuum_defer_cleanup_age</varname> configuration parameter</primary> - </indexterm> - </term> - <listitem> - <para> - Specifies the number of transactions by which <command>VACUUM</command> and - <link linkend="storage-hot"><acronym>HOT</acronym> updates</link> - 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</filename> - file or on the server command line. - </para> - <para> - You should also consider setting <varname>hot_standby_feedback</varname> - on standby server(s) as an alternative to using this parameter. - </para> - <para> - This does not prevent cleanup of dead rows which have reached the age - specified by <varname>old_snapshot_threshold</varname>. - </para> - </listitem> - </varlistentry> - </variablelist> </sect2> diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 9d0deaeeb80..cf61b2ed2a1 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -944,12 +944,11 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' retained by replication slots. </para> <para> - Similarly, <xref linkend="guc-hot-standby-feedback"/> - and <xref linkend="guc-vacuum-defer-cleanup-age"/> provide protection against - relevant rows being removed by vacuum, but the former provides no - protection during any time period when the standby is not connected, - and the latter often needs to be set to a high value to provide adequate - protection. Replication slots overcome these disadvantages. + Similarly, <xref linkend="guc-hot-standby-feedback"/> on its own, without + also using a replication slot, provides protection against relevant rows + being removed by vacuum, but provides no protection during any time period + when the standby is not connected. Replication slots overcome these + disadvantages. </para> <sect3 id="streaming-replication-slots-manipulation"> <title>Querying and Manipulating Replication Slots</title> @@ -1911,17 +1910,6 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' </para> <para> - Another option is to increase <xref linkend="guc-vacuum-defer-cleanup-age"/> - on the primary server, so that dead rows will not be cleaned up as quickly - as they normally would be. This will allow more time for queries to - execute before they are canceled on the standby, without having to set - a high <varname>max_standby_streaming_delay</varname>. However it is - difficult to guarantee any specific execution-time window with this - approach, since <varname>vacuum_defer_cleanup_age</varname> is measured in - transactions executed on the primary server. - </para> - - <para> The number of query cancels and the reason for them can be viewed using the <structname>pg_stat_database_conflicts</structname> system view on the standby server. The <structname>pg_stat_database</structname> system view also contains @@ -2257,8 +2245,7 @@ HINT: You can then restart the server after making the necessary configuration </para> <para> - On the primary, parameters <xref linkend="guc-wal-level"/> and - <xref linkend="guc-vacuum-defer-cleanup-age"/> can be used. + On the primary, the <xref linkend="guc-wal-level"/> parameter can be used. <xref linkend="guc-max-standby-archive-delay"/> and <xref linkend="guc-max-standby-streaming-delay"/> have no effect if set on the primary. @@ -2268,9 +2255,6 @@ HINT: You can then restart the server after making the necessary configuration On the standby, parameters <xref linkend="guc-hot-standby"/>, <xref linkend="guc-max-standby-archive-delay"/> and <xref linkend="guc-max-standby-streaming-delay"/> can be used. - <xref linkend="guc-vacuum-defer-cleanup-age"/> has no effect - as long as the server remains in standby mode, though it will - become relevant if the standby becomes primary. </para> </sect2> |