<!-- $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>

<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 aHot Standby connection, as

described in <xref linkend="hot-standby">.The recommended value is

<literal>0</> unless you haveclear reason to increase it. The purpose

of the parameter is toallow the user to specify an approximate time

delay before cleanupoccurs. However, it should be noted that there is

no direct link withany specific time delay and so the results will be

application andinstallation specific, as well as variable over time,

depending uponthe transaction rate (of writes only).

</para>

</listitem>

</varlistentry>

<!-- $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>

</listitem>

<listitem>

<para>

LISTEN,UNLISTEN,NOTIFY

<command>LISTEN</>, <command>UNLISTEN</>, <command>NOTIFY</>

</para>

</listitem>

</itemizedlist>

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 thatget in their way, after a grace period. This is similar

to the possibilityof being canceled by the deadlock detector. But in this

case, the standbyrecovery process always wins, since the replayed actions

must not fail.This also ensures that replication does not fall behind

while waiting for aquery to complete. This prioritization presumes that

the standby existsprimarily for high availability, and that adjusting the

grace periodwill allow a sufficient guard against unexpected cancellation.

</para>

<para>