aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2011-02-10 21:00:29 +0200
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2011-02-10 21:04:02 +0200
commitb186523fd97ce02ffbb7e21d5385a047deeef4f6 (patch)
tree00e70beaaa8529b291f85b214ee87fc686083cea /doc/src
parent4c468b37a281941afd3bf61c782b20def8c17047 (diff)
downloadpostgresql-b186523fd97ce02ffbb7e21d5385a047deeef4f6.tar.gz
postgresql-b186523fd97ce02ffbb7e21d5385a047deeef4f6.zip
Send status updates back from standby server to master, indicating how far
the standby has written, flushed, and applied the WAL. At the moment, this is for informational purposes only, the values are only shown in pg_stat_replication system view, but in the future they will also be needed for synchronous replication. Extracted from Simon riggs' synchronous replication patch by Robert Haas, with some tweaking by me.
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/config.sgml23
-rw-r--r--doc/src/sgml/monitoring.sgml7
-rw-r--r--doc/src/sgml/protocol.sgml76
3 files changed, 104 insertions, 2 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 5a43774b33d..63c6283f915 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1984,6 +1984,29 @@ SET ENABLE_SEQSCAN TO OFF;
</listitem>
</varlistentry>
+ <varlistentry id="guc-wal-receiver-status-interval" xreflabel="wal_receiver_status_interval">
+ <term><varname>wal_receiver_status_interval</varname> (<type>integer</type>)</term>
+ <indexterm>
+ <primary><varname>wal_receiver_status_interval</> configuration parameter</primary>
+ </indexterm>
+ <listitem>
+ <para>
+ Specifies the minimum frequency, in seconds, for the WAL receiver
+ process on the standby to send information about replication progress
+ to the primary, where they can be seen using the
+ <literal>pg_stat_replication</literal> view. The standby will report
+ the last transaction log position it has written, the last position it
+ has flushed to disk, and the last position it has applied. Updates are
+ sent each time the write or flush positions changed, or at least as
+ often as specified by this parameter. Thus, the apply position may
+ lag slightly behind the true position. Setting this parameter to zero
+ disables status updates completely. This parameter can only be set in
+ the <filename>postgresql.conf</> file or on the server command line.
+ The default value is 10 seconds.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-vacuum-defer-cleanup-age" xreflabel="vacuum_defer_cleanup_age">
<term><varname>vacuum_defer_cleanup_age</varname> (<type>integer</type>)</term>
<indexterm>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 2e8427a40f1..58e3459e678 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -298,8 +298,11 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
<entry><structname>pg_stat_replication</><indexterm><primary>pg_stat_replication</primary></indexterm></entry>
<entry>One row per WAL sender process, showing process <acronym>ID</>,
user OID, user name, application name, client's address and port number,
- time at which the server process began execution, current WAL sender
- state and transaction log location. The columns detailing what exactly
+ time at which the server process began execution, and the current WAL
+ sender state and transaction log location. In addition, the standby
+ reports the last transaction log position it received and wrote, the last
+ position it flushed to disk, and the last position it replayed, and this
+ information is also displayed here. The columns detailing what exactly
the connection is doing are only visible if the user examining the view
is a superuser.
</entry>
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index c09d961d67e..c923d3b154c 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1469,6 +1469,82 @@ The commands accepted in walsender mode are:
shutdown), it will send a CommandComplete message before exiting.
This might not happen during an abnormal shutdown, of course.
</para>
+
+ <para>
+ The receiving process can send a status update back to the sender at
+ any time, using the following message format (also in the payload of
+ a CopyData message):
+ </para>
+
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ Standby status update (F)
+ </term>
+ <listitem>
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ Byte1('r')
+ </term>
+ <listitem>
+ <para>
+ Identifies the message as a receiver status update.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ Byte8
+ </term>
+ <listitem>
+ <para>
+ The location of the last WAL byte + 1 received and written to disk
+ in the standby, in XLogRecPtr format.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ Byte8
+ </term>
+ <listitem>
+ <para>
+ The location of the last WAL byte + 1 flushed to disk in
+ the standby, in XLogRecPtr format.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ Byte8
+ </term>
+ <listitem>
+ <para>
+ The location of the last WAL byte + 1 applied in the standby, in
+ XLogRecPtr format.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ Byte8
+ </term>
+ <listitem>
+ <para>
+ The server's system clock at the time of transmission,
+ given in TimestampTz format.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
</listitem>
</varlistentry>