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

Copy editing of Hot Standby docs. Some clarifications, addition

Browse Source 
of missing items and minor edits.
This commit is contained in:
Simon Riggs 2010-02-20 10:07:27 +00:00
parent 3f56ca1d49
commit 7363021df3
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.47 2010/02/19 00:15:25 momjian Exp $ --> <!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.48 2010/02/20 10:07:27 sriggs 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>
@ -1079,8 +1079,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
The data on the standby takes some time to arrive from the primary server The data on the standby takes some time to arrive from the primary server
so there will be a measurable delay between primary and standby. Running the so there will be a measurable delay between primary and standby. Running the
same query nearly simultaneously on both primary and standby might therefore same query nearly simultaneously on both primary and standby might therefore
return differing results. Eventually, the standby will be return differing results. We say that data on the standby is
consistent with the primary. <literal>eventually consistent</literal> with the primary.
Queries executed on the standby will be correct with regard to the transactions Queries executed on the standby will be correct with regard to the transactions
that had been recovered at the start of the query, or start of first statement that had been recovered at the start of the query, or start of first statement
in the case of serializable transactions. In comparison with the primary, in the case of serializable transactions. In comparison with the primary,
@ -1203,12 +1203,12 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
<command>LOCK TABLE</> that explicitly requests a mode higher than <literal>ROW EXCLUSIVE MODE</>. <command>LOCK</> that explicitly requests a mode higher than <literal>ROW EXCLUSIVE MODE</>.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
<command>LOCK TABLE</> in short default form, since it requests <literal>ACCESS EXCLUSIVE MODE</>. <command>LOCK</> in short default form, since it requests <literal>ACCESS EXCLUSIVE MODE</>.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -1245,7 +1245,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
Sequence update - <function>nextval()</> Sequence updates - <function>nextval()</>, <function>setval()</>
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -1262,8 +1262,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
subtle differences in behavior between read-only transactions subtle differences in behavior between read-only transactions
run on a standby and run during normal operation. run on a standby and run during normal operation.
It is possible that <command>LISTEN</>, <command>UNLISTEN</>, It is possible that <command>LISTEN</>, <command>UNLISTEN</>,
<command>NOTIFY</>, and temporary tables might be allowed in a and temporary tables might be allowed in a future release.
future release.
</para> </para>
<para> <para>
@ -1483,7 +1482,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
Three-way deadlocks are possible between <literal>AccessExclusiveLocks</> arriving from Three-way deadlocks are possible between <literal>AccessExclusiveLocks</> arriving from
the primary, cleanup WAL records that require buffer cleanup locks, and the primary, cleanup WAL records that require buffer cleanup locks, and
user requests that are waiting behind replayed <literal>AccessExclusiveLocks</>. Deadlocks user requests that are waiting behind replayed <literal>AccessExclusiveLocks</>. Deadlocks
are resolved by time-out when they exceed <varname>max_standby_delay</>. are resolved immediately, should they occur, though they are thought to be
rare in practice.
</para> </para>
<para> <para>
@ -1516,8 +1516,9 @@ LOG: database system is ready to accept read only connections
</programlisting> </programlisting>
Consistency information is recorded once per checkpoint on the primary, as long Consistency information is recorded once per checkpoint on the primary, as long
as <varname>recovery_connections</> is enabled on the primary. If this parameter as <varname>recovery_connections</> is enabled on the primary. It is not possible
is disabled, it is not possible to enable recovery connections on the standby. to enable recovery connections on the standby when reading WAL written during the
period that <varname>recovery_connections</> was disabled on the primary.
Reaching a consistent state can also be delayed in the presence Reaching a consistent state can also be delayed in the presence
of both of these conditions: of both of these conditions: