aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2011-08-31 12:37:37 +0300
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2011-08-31 12:37:37 +0300
commit5cfe33fe7bb5f5a29e9c2f6780c8278b8a7e5735 (patch)
tree8b9021579fb0d7a275507895426e94e567742fbb
parent731ebb64b77571e1dc391ba96c4bf9c685a07f2a (diff)
downloadpostgresql-5cfe33fe7bb5f5a29e9c2f6780c8278b8a7e5735.tar.gz
postgresql-5cfe33fe7bb5f5a29e9c2f6780c8278b8a7e5735.zip
The replication status values in pg_stat_replication was changed to
lowercase earlier, but documentation was not updated. Update the docs. Fujii Masao
-rw-r--r--doc/src/sgml/config.sgml2
-rw-r--r--doc/src/sgml/high-availability.sgml6
2 files changed, 4 insertions, 4 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 67e722f7572..4b351695a49 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2103,7 +2103,7 @@ SET ENABLE_SEQSCAN TO OFF;
this standby server confirms receipt of their data.
The synchronous standby will be the first standby named in this list
that is both currently connected and streaming data in real-time
- (as shown by a state of <literal>STREAMING</literal> in the
+ (as shown by a state of <literal>streaming</literal> in the
<link linkend="monitoring-stats-views-table">
<literal>pg_stat_replication</></link> view).
Other standby servers appearing later in this list represent potential
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c1680301d3f..8bcdc07a763 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1088,14 +1088,14 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
<para>
When a standby first attaches to the primary, it will not yet be properly
- synchronized. This is described as <literal>CATCHUP</> mode. Once
+ synchronized. This is described as <literal>catchup</> mode. Once
the lag between standby and primary reaches zero for the first time
- we move to real-time <literal>STREAMING</> state.
+ we move to real-time <literal>streaming</> state.
The catch-up duration may be long immediately after the standby has
been created. If the standby is shut down, then the catch-up period
will increase according to the length of time the standby has been down.
The standby is only able to become a synchronous standby
- once it has reached <literal>STREAMING</> state.
+ once it has reached <literal>streaming</> state.
</para>
<para>