mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Minor markup improvements for Hot Standby documentation.

Browse Source
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"> <chapter Id="runtime-config">
<title>Server Configuration</title> <title>Server Configuration</title>
@ -1977,14 +1977,14 @@ SET ENABLE_SEQSCAN TO OFF;
<acronym>HOT</> updates will defer cleanup of dead row versions. The <acronym>HOT</> updates will defer cleanup of dead row versions. The
default is 0 transactions, meaning that dead row versions will be 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 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"> value when planning or maintaining a Hot Standby connection, as
configuration. The recommended value is <literal>0</> unless you have described in <xref linkend="hot-standby">. The recommended value is
clear reason to increase it. The purpose of the parameter is to <literal>0</> unless you have clear reason to increase it. The purpose
allow the user to specify an approximate time delay before cleanup of the parameter is to allow the user to specify an approximate time
occurs. However, it should be noted that there is no direct link with delay before cleanup occurs. However, it should be noted that there is
any specific time delay and so the results will be application and no direct link with any specific time delay and so the results will be
installation specific, as well as variable over time, depending upon application and installation specific, as well as variable over time,
the transaction rate (of writes only). depending upon the transaction rate (of writes only).
</para> </para>
</listitem> </listitem>
</varlistentry> </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"> <chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title> <title>High Availability, Load Balancing, and Replication</title>
@ -1330,7 +1330,7 @@ if (!triggered)
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
LISTEN, UNLISTEN, NOTIFY <command>LISTEN</>, <command>UNLISTEN</>, <command>NOTIFY</>
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
@ -1437,14 +1437,14 @@ if (!triggered)
Some WAL redo actions will be for <acronym>DDL</> execution. These DDL Some WAL redo actions will be for <acronym>DDL</> execution. These DDL
actions are replaying changes that have already committed on the primary 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 node, so they must not fail on the standby node. These DDL locks take
priority and will automatically *cancel* any read-only transactions that priority and will automatically <emphasis>cancel</> any read-only
get in their way, after a grace period. This is similar to the possibility transactions that get in their way, after a grace period. This is similar
of being canceled by the deadlock detector. But in this case, the standby to the possibility of being canceled by the deadlock detector. But in this
recovery process always wins, since the replayed actions must not fail. case, the standby recovery process always wins, since the replayed actions
This also ensures that replication does not fall behind while waiting for a must not fail. This also ensures that replication does not fall behind
query to complete. This prioritization presumes that the standby exists while waiting for a query to complete. This prioritization presumes that
primarily for high availability, and that adjusting the grace period the standby exists primarily for high availability, and that adjusting the
will allow a sufficient guard against unexpected cancellation. grace period will allow a sufficient guard against unexpected cancellation.
</para> </para>
<para> <para>