From 9b2c14cf115452fa595fa01c7943f4e532b8c86c Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Tue, 22 Jun 2010 02:57:50 +0000 Subject: [PATCH] Minor markup improvements for Hot Standby documentation. --- doc/src/sgml/config.sgml | 18 +++++++++--------- doc/src/sgml/high-availability.sgml | 20 ++++++++++---------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 75127f972d..298ccb60e1 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1,4 +1,4 @@ - + Server Configuration @@ -1977,14 +1977,14 @@ SET ENABLE_SEQSCAN TO OFF; 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 - configuration. The recommended value is 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 . The recommended value is + 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). diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 2ac79245d0..b94c19988f 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1,4 +1,4 @@ - + High Availability, Load Balancing, and Replication @@ -1330,7 +1330,7 @@ if (!triggered) - LISTEN, UNLISTEN, NOTIFY + LISTEN, UNLISTEN, NOTIFY @@ -1437,14 +1437,14 @@ if (!triggered) Some WAL redo actions will be for 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 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.