rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor markup improvements for Hot Standby documentation.

This commit is contained in:
Robert Haas 2010-06-22 02:57:50 +00:00
parent 2e8a832dd6
commit 9b2c14cf11
2 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
doc/src/sgml/config.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.281 2010/06/15 07:52:10 itagaki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.282 2010/06/22 02:57:49 rhaas Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -1977,14 +1977,14 @@ SET ENABLE_SEQSCAN TO OFF;
<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 <xref linkend="hot-standby">
configuration. 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).
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>

20
doc/src/sgml/high-availability.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.73 2010/06/11 10:13:08 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.74 2010/06/22 02:57:50 rhaas Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
@ -1330,7 +1330,7 @@ if (!triggered)
</listitem>
<listitem>
<para>
LISTEN, UNLISTEN, NOTIFY
<command>LISTEN</>, <command>UNLISTEN</>, <command>NOTIFY</>
</para>
</listitem>
</itemizedlist>
@ -1437,14 +1437,14 @@ if (!triggered)
Some WAL redo actions will be for <acronym>DDL</> execution. These DDL
actions are replaying changes that have already committed on the primary
node, so they must not fail on the standby node. These DDL locks take
priority and will automatically *cancel* any read-only transactions that
get in their way, after a grace period. This is similar to the possibility
of being canceled by the deadlock detector. But in this case, the standby
recovery process always wins, since the replayed actions must not fail.
This also ensures that replication does not fall behind while waiting for a
query to complete. This prioritization presumes that the standby exists
primarily for high availability, and that adjusting the grace period
will allow a sufficient guard against unexpected cancellation.
priority and will automatically <emphasis>cancel</> any read-only
transactions that get in their way, after a grace period. This is similar
to the possibility of being canceled by the deadlock detector. But in this
case, the standby recovery process always wins, since the replayed actions
must not fail. This also ensures that replication does not fall behind
while waiting for a query to complete. This prioritization presumes that
the standby exists primarily for high availability, and that adjusting the
grace period will allow a sufficient guard against unexpected cancellation.
</para>
<para>