*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***************
*** 801,815 **** if (!triggered)
        </listitem>
       <listitem>
        <para>
!        Set up continuous archiving from the primary to a WAL archive located
!        in a directory on the standby server. In particular, set
!        <xref linkend="guc-archive-mode"> and
!        <xref linkend="guc-archive-command">
!        to archive WAL files in a location accessible from the standby
         (see <xref linkend="backup-archiving-wal">).
        </para>
       </listitem>
- 
       <listitem>
        <para>
         Set <xref linkend="guc-listen-addresses"> and authentication options
--- 801,812 ----
        </listitem>
       <listitem>
        <para>
!        Set up continuous archiving from the primary to a WAL archive accessible
!        from the standby. Ensure that <xref linkend="guc-archive-mode"> and
!        <xref linkend="guc-archive-command"> are set appropriately on the primary
         (see <xref linkend="backup-archiving-wal">).
        </para>
       </listitem>
       <listitem>
        <para>
         Set <xref linkend="guc-listen-addresses"> and authentication options
***************
*** 821,827 **** if (!triggered)
         On systems that support the keepalive socket option, setting
         <xref linkend="guc-tcp-keepalives-idle">,
         <xref linkend="guc-tcp-keepalives-interval"> and
!        <xref linkend="guc-tcp-keepalives-count"> helps the master promptly
         notice a broken connection.
        </para>
       </listitem>
--- 818,824 ----
         On systems that support the keepalive socket option, setting
         <xref linkend="guc-tcp-keepalives-idle">,
         <xref linkend="guc-tcp-keepalives-interval"> and
!        <xref linkend="guc-tcp-keepalives-count"> helps the primary promptly
         notice a broken connection.
        </para>
       </listitem>
***************
*** 829,834 **** if (!triggered)
--- 826,834 ----
        <para>
         Set the maximum number of concurrent connections from the standby servers
         (see <xref linkend="guc-max-wal-senders"> for details).
+        Since those connections are for superusers,
+        <xref linkend="guc-superuser-reserved-connections"> should be
+        set accordingly.
        </para>
       </listitem>
       <listitem>
***************
*** 858,872 **** if (!triggered)
       <listitem>
        <para>
         Create a recovery command file <filename>recovery.conf</> in the data
!        directory on the standby server. Set <varname>restore_command</varname>
!        as you would in normal recovery from a continuous archiving backup
!        (see <xref linkend="backup-pitr-recovery">). <literal>pg_standby</> or
!        similar tools that wait for the next WAL file to arrive cannot be used
!        with streaming replication, as the server handles retries and waiting
!        itself. Enable <varname>standby_mode</varname>. Set
!        <varname>primary_conninfo</varname> to point to the primary server.
        </para>
- 
       </listitem>
       <listitem>
        <para>
--- 858,908 ----
       <listitem>
        <para>
         Create a recovery command file <filename>recovery.conf</> in the data
!        directory on the standby server.
!        <itemizedlist>
!         <listitem>
!          <para>
!           Enable <xref linkend="standby-mode">.
!          </para>
!         </listitem>
!         <listitem>
!          <para>
!           Set <xref linkend="primary-conninfo"> to point to the primary server.
!           The host name (or host address) and port number which the primary server
!           listens on should be specified in this string. Also ensure that a role with
!           the <literal>SUPERUSER</> and <literal>LOGIN</> privileges on the
!           primary is set (see
!           <xref linkend="streaming-replication-authentication">). Note that
!           the password needs to be set if the primary demands password
!           authentication.
!          </para>
!         </listitem>
!         <listitem>
!          <para>
!           Set <xref linkend="restore-command"> as you would in normal recovery
!           from a continuous archiving backup
!           (see <xref linkend="backup-pitr-recovery">).
!           <application>pg_standby</> or similar tools that wait for the next
!           WAL file to arrive cannot be used with streaming replication,
!           as the server handles retries and waiting itself.
!          </para>
!         </listitem>
!         <listitem>
!          <para>
!           Specifies the trigger file whose presence ends the standby's
!           recovery in the <xref linkend="trigger-file">. If you have no
!           plan to perform failover, this parameter is not required.
!          </para>
!         </listitem>
!        </itemizedlist>
!        A simple example of the <filename>recovery.conf</> is:
! <programlisting>
! standby_mode = 'on'
! primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
! restore_command = 'cp /path/to/archive/%f %p'
! trigger_file = '/path/to/trigger_file'
! </programlisting>
        </para>
       </listitem>
       <listitem>
        <para>
***************
*** 929,934 **** primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
--- 965,991 ----
        <varname>primary_conninfo</varname> then a FATAL error will be raised.
      </para>
     </sect2>
+ 
+    <sect2 id="streaming-replication-monitor">
+     <title>Monitor</title>
+     <para>
+      The WAL files required for the standby's recovery are not deleted from
+      the <filename>pg_xlog</> directory on the primary while the standby is
+      connecting to the standby. If the standby lags far behind the primary,
+      many WAL files would accumulate in there, and might cause a disk full
+      failure. So it is very important to check periodically how far the
+      standby lags behind and eliminate the cause of the delay as soon as
+      possible. You can check that by comparing the current WAL write
+      location on the primary with the last WAL location received by the
+      standby. The former and the latter can be taken from the
+      <function>pg_current_xlog_location</> on the primary and the
+      <function>pg_last_xlog_receive_location</> on the standby,
+      respectively (see <xref linkend="functions-admin-backup-table"> and
+      <xref linkend="functions-recovery-info-table"> for details).
+      Also the latter can be taken from the <command>ps</> message of
+      WAL receiver process (see <xref linkend="monitoring-ps"> for details).
+     </para>
+    </sect2>
    </sect1>
  
    <sect1 id="warm-standby-failover">
***************
*** 1798,1831 **** LOG:  database system is ready to accept read only connections
    </indexterm>
  
     <para>
!     In a warm standby configuration, it is possible to offload the expense of
!     taking periodic base backups from the primary server; instead base backups
!     can be made by backing
      up a standby server's files.  This concept is generally known as
      incrementally updated backups, log change accumulation, or more simply,
      change accumulation.
-    </para>
- 
-    <para>
-     If we take a file system backup of the standby server's data
-     directory while it is processing
-     logs shipped from the primary, we will be able to reload that backup and
-     restart the standby's recovery process from the last restart point.
-     We no longer need to keep WAL files from before the standby's restart point.
      If recovery is needed, it will be faster to recover from the incrementally
      updated backup than from the original base backup.
     </para>
  
     <para>
!     Since the standby server is not <quote>live</>, it is not possible to
!     use <function>pg_start_backup()</> and <function>pg_stop_backup()</>
!     to manage the backup process; it will be up to you to determine how
!     far back you need to keep WAL segment files to have a recoverable
!     backup.  You can do this by running <application>pg_controldata</>
!     on the standby server to inspect the control file and determine the
!     current checkpoint WAL location, or by using the
!     <varname>log_checkpoints</> option to print values to the standby's
!     server log.
     </para>
    </sect1>
  
--- 1855,1918 ----
    </indexterm>
  
     <para>
!     In file-based log shipping or streaming replication,
!     it is possible to offload the expense of taking periodic base backups
!     from the primary server; instead base backups can be made by backing
      up a standby server's files.  This concept is generally known as
      incrementally updated backups, log change accumulation, or more simply,
      change accumulation.
      If recovery is needed, it will be faster to recover from the incrementally
      updated backup than from the original base backup.
     </para>
  
     <para>
!     The procedure for taking a file system backup of the standby server's
!     data directory while it is processing logs shipped from the primary is:
!    <orderedlist>
!     <listitem>
!      <para>
!       Perform the backup, without using <function>pg_start_backup</> and
!       <function>pg_stop_backup</>. But note that the <filename>pg_control</>
!       file must be backed up first like the following:
! <programlisting>
! cp /var/lib/pgsql/data/global/pg_control /tmp
! cp -r /var/lib/pgsql/data /path/to/backup
! mv /tmp/pg_control /path/to/backup/data/global
! </programlisting>
!       This avoids the problem that we might fail to restore a consistent
!       database state because recovery starts from the later restart point
!       than the start of the backup.
!      </para>
!     </listitem>
!     <listitem>
!      <para>
!       Take the backup ending WAL location by calling the <function>
!       pg_last_xlog_replay_location</> function at the end of the backup,
!       keep the record of it with the backup.
! <programlisting>
! psql -c "select pg_last_xlog_replay_location();" > /path/to/backup/end_location
! </programlisting>
!       When recovering from the incrementally updated backup, the server
!       can begin accepting connections and complete the recovery successfully
!       before the database has become consistent. To avoid these problems,
!       you must check whether the database has been consistent before
!       your users try to connect to the server and when archive recovery ends.
!       You can do this by comparing the progress of the recovery with
!       the backup ending WAL location recorded. The progress of the recovery
!       is also taken from the <function>pg_last_xlog_replay_location</> function.
!      </para>
!      <para>
!      </para>
!     </listitem>
!    </orderedlist>
!    </para>
! 
!    <para>
!     You no longer need to keep WAL files from before the restart point of the backup.
!     That restart point can be taken by running <application>pg_controldata</>
!     on the backup to inspect the <filename>pg_control</> file and determine the
!     latest checkpoint's REDO location, or by using the <varname>log_checkpoints</>
!     option to print values to the standby's server log.
     </para>
    </sect1>
  
*** a/doc/src/sgml/monitoring.sgml
--- b/doc/src/sgml/monitoring.sgml
***************
*** 85,90 **** postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
--- 85,107 ----
    </para>
  
    <para>
+    In streaming replication (see <xref linkend="streaming-replication"> for details),
+    WAL sender process is listed in the <command>ps</> display on the primary server.
+    The form of its command line display is:
+ <screen>
+ postgres: wal sender process <replaceable>user</> <replaceable>host</> streaming <replaceable>location</>
+ </screen>
+    The user and host items remain the same for the life of the replication connection.
+    The location indicates how far WAL sender process has sent the WAL.
+    On the other hand, WAL receiver process is listed in the <command>ps</> display
+    on the standby server. The form of its command line display is:
+ <screen>
+ postgres: wal receiver process streaming <replaceable>location</>
+ </screen>
+    The location indicates how far WAL receiver has received the WAL.
+   </para>
+ 
+   <para>
     If you have turned off <xref linkend="guc-update-process-title"> then the
     activity indicator is not updated; the process title is set only once
     when a new process is launched.  On some platforms this saves a measurable
*** a/doc/src/sgml/recovery-config.sgml
--- b/doc/src/sgml/recovery-config.sgml
***************
*** 11,30 ****
  
     <para>
        This chapter describes the settings available in
!       <filename>recovery.conf</> file. They apply only for the duration of
        the recovery.  (A sample file, <filename>share/recovery.conf.sample</>,
        exists in the installation's <filename>share/</> directory.)  They must
        be reset for any subsequent recovery you wish to perform. They cannot
        be changed once recovery has begun.
     </para>
  
    <sect1 id="archive-recovery-settings">
  
!     <title>Archive recovery settings</title>
       <variablelist>
  
       <varlistentry id="restore-command" xreflabel="restore_command">
        <term><varname>restore_command</varname> (<type>string</type>)</term>
        <listitem>
         <para>
          The shell command to execute to retrieve an archived segment of
--- 11,56 ----
  
     <para>
        This chapter describes the settings available in
!       <filename>recovery.conf</><indexterm><primary>recovery.conf</></> file.
!       They apply only for the duration of
        the recovery.  (A sample file, <filename>share/recovery.conf.sample</>,
        exists in the installation's <filename>share/</> directory.)  They must
        be reset for any subsequent recovery you wish to perform. They cannot
        be changed once recovery has begun.
+       Upon completion of the recovery, <filename>recovery.conf</> is renamed
+       to <filename>recovery.done</> (to prevent accidentally re-entering
+       recovery mode later).
+    </para>
+ 
+    <para>
+     All parameter names are case-sensitive. Every parameter takes a
+     value of one of four types: Boolean, integer, string or timestamp.
+     Boolean values can be written as <literal>on</literal>,
+     <literal>off</literal>, <literal>true</literal>,
+     <literal>false</literal>, <literal>yes</literal>,
+     <literal>no</literal>, <literal>1</literal>,
+     <literal>0</literal> (all case-insensitive) or any unambiguous prefix
+     of these.
+    </para>
+ 
+    <para>
+     One parameter is specified per line. The equal sign between name and
+     value is optional. Whitespace is insignificant and blank lines are
+     ignored. Hash marks (<literal>#</literal>) designate the rest of the
+     line as a comment.  A parameter value must be single-quoted. A single
+     quote must not be embedded in a parameter value.
     </para>
  
    <sect1 id="archive-recovery-settings">
  
!     <title>Archive Recovery</title>
       <variablelist>
  
       <varlistentry id="restore-command" xreflabel="restore_command">
        <term><varname>restore_command</varname> (<type>string</type>)</term>
+       <indexterm>
+        <primary><varname>restore_command</> configuration parameter</primary>
+       </indexterm>
        <listitem>
         <para>
          The shell command to execute to retrieve an archived segment of
***************
*** 61,66 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
--- 87,95 ----
  
       <varlistentry id="restartpoint-command" xreflabel="restartpoint_command">
        <term><varname>restartpoint_command</varname> (<type>string</type>)</term>
+       <indexterm>
+        <primary><varname>restartpoint_command</> configuration parameter</primary>
+       </indexterm>
        <listitem>
         <para>
          This parameter specifies a shell command that will be executed at
***************
*** 87,92 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
--- 116,124 ----
  
       <varlistentry id="recovery-end-command" xreflabel="recovery_end_command">
        <term><varname>recovery_end_command</varname> (<type>string</type>)</term>
+       <indexterm>
+        <primary><varname>recovery_end_command</> configuration parameter</primary>
+       </indexterm>
        <listitem>
         <para>
          This parameter specifies a shell command that will be executed once only
***************
*** 111,123 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
  
    <sect1 id="recovery-target-settings">
  
!     <title>Recovery target settings</title>
       <variablelist>
  
       <varlistentry id="recovery-target-time" xreflabel="recovery_target_time">
        <term><varname>recovery_target_time</varname>
             (<type>timestamp</type>)
        </term>
        <listitem>
         <para>
          This parameter specifies the time stamp up to which recovery
--- 143,158 ----
  
    <sect1 id="recovery-target-settings">
  
!     <title>Recovery Target</title>
       <variablelist>
  
       <varlistentry id="recovery-target-time" xreflabel="recovery_target_time">
        <term><varname>recovery_target_time</varname>
             (<type>timestamp</type>)
        </term>
+       <indexterm>
+        <primary><varname>recovery_target_time</> configuration parameter</primary>
+       </indexterm>
        <listitem>
         <para>
          This parameter specifies the time stamp up to which recovery
***************
*** 132,138 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
       </varlistentry>
  
       <varlistentry id="recovery-target-xid" xreflabel="recovery_target_xid">
!       <term><varname>recovery_target_xid</varname> (<type>string</type>)</term>
        <listitem>
         <para>
          This parameter specifies the transaction ID up to which recovery
--- 167,176 ----
       </varlistentry>
  
       <varlistentry id="recovery-target-xid" xreflabel="recovery_target_xid">
!       <term><varname>recovery_target_xid</varname> (<type>integer</type>)</term>
!       <indexterm>
!        <primary><varname>recovery_target_xid</> configuration parameter</primary>
!       </indexterm>
        <listitem>
         <para>
          This parameter specifies the transaction ID up to which recovery
***************
*** 155,160 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
--- 193,201 ----
        <term><varname>recovery_target_inclusive</varname>
          (<type>boolean</type>)
        </term>
+       <indexterm>
+        <primary><varname>recovery_target_inclusive</> configuration parameter</primary>
+       </indexterm>
        <listitem>
         <para>
          Specifies whether we stop just after the specified recovery target
***************
*** 174,179 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
--- 215,223 ----
        <term><varname>recovery_target_timeline</varname>
          (<type>string</type>)
        </term>
+       <indexterm>
+        <primary><varname>recovery_target_timeline</> configuration parameter</primary>
+       </indexterm>
        <listitem>
         <para>
          Specifies recovering into a particular timeline.  The default is
***************
*** 191,201 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
  
    <sect1 id="standby-settings">
  
!     <title>Standby server settings</title>
       <variablelist>
  
         <varlistentry id="standby-mode" xreflabel="standby_mode">
          <term><varname>standby_mode</varname> (<type>boolean</type>)</term>
          <listitem>
           <para>
            Specifies whether to start the <productname>PostgreSQL</> server as
--- 235,248 ----
  
    <sect1 id="standby-settings">
  
!     <title>Standby Server</title>
       <variablelist>
  
         <varlistentry id="standby-mode" xreflabel="standby_mode">
          <term><varname>standby_mode</varname> (<type>boolean</type>)</term>
+       <indexterm>
+        <primary><varname>standby_mode</> configuration parameter</primary>
+       </indexterm>
          <listitem>
           <para>
            Specifies whether to start the <productname>PostgreSQL</> server as
***************
*** 209,214 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
--- 256,264 ----
         </varlistentry>
         <varlistentry id="primary-conninfo" xreflabel="primary_conninfo">
          <term><varname>primary_conninfo</varname> (<type>string</type>)</term>
+       <indexterm>
+        <primary><varname>primary_conninfo</> configuration parameter</primary>
+       </indexterm>
          <listitem>
           <para>
            Specifies a connection string to be used for the standby server
***************
*** 221,247 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
            defaults are used.
           </para>
           <para>
-           The built-in replication requires that a host name (or host address)
-           or port number which the primary server listens on be
-           specified in this string. Also ensure that a role with
-           the <literal>SUPERUSER</> and <literal>LOGIN</> privileges on the
-           primary is set (see
-           <xref linkend="streaming-replication-authentication">). Note that
-           the password needs to be set if the primary demands password
-           authentication.
-          </para>
-          <para>
            This setting has no effect if <varname>standby_mode</> is <literal>off</>.
           </para>
          </listitem>
         </varlistentry>
         <varlistentry id="trigger-file" xreflabel="trigger_file">
          <term><varname>trigger_file</varname> (<type>string</type>)</term>
          <listitem>
           <para>
            Specifies a trigger file whose presence ends recovery in the
!           standby. If no trigger file is specified, the standby never exits
!           recovery.
            This setting has no effect if <varname>standby_mode</> is <literal>off</>.
           </para>
          </listitem>
--- 271,291 ----
            defaults are used.
           </para>
           <para>
            This setting has no effect if <varname>standby_mode</> is <literal>off</>.
           </para>
          </listitem>
         </varlistentry>
         <varlistentry id="trigger-file" xreflabel="trigger_file">
          <term><varname>trigger_file</varname> (<type>string</type>)</term>
+       <indexterm>
+        <primary><varname>trigger_file</> configuration parameter</primary>
+       </indexterm>
          <listitem>
           <para>
            Specifies a trigger file whose presence ends recovery in the
!           standby. This can be a path relative to the data directory or
!           an absolute path. If no trigger file is specified, the standby
!           never exits recovery.
            This setting has no effect if <varname>standby_mode</> is <literal>off</>.
           </para>
          </listitem>
*** a/doc/src/sgml/storage.sgml
--- b/doc/src/sgml/storage.sgml
***************
*** 30,36 **** managed by different server instances, can exist on the same machine.
  The <varname>PGDATA</> directory contains several subdirectories and control
  files, as shown in <xref linkend="pgdata-contents-table">.  In addition to
  these required items, the cluster configuration files
! <filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename>, and
  <filename>pg_ident.conf</filename> are traditionally stored in
  <varname>PGDATA</> (although in <productname>PostgreSQL</productname> 8.0 and
  later, it is possible to keep them elsewhere).
--- 30,37 ----
  The <varname>PGDATA</> directory contains several subdirectories and control
  files, as shown in <xref linkend="pgdata-contents-table">.  In addition to
  these required items, the cluster configuration files
! <filename>postgresql.conf</filename>, <filename>recovery.conf</filename>,
! <filename>pg_hba.conf</filename>, and
  <filename>pg_ident.conf</filename> are traditionally stored in
  <varname>PGDATA</> (although in <productname>PostgreSQL</productname> 8.0 and
  later, it is possible to keep them elsewhere).
*** a/src/backend/access/transam/recovery.conf.sample
--- b/src/backend/access/transam/recovery.conf.sample
***************
*** 88,94 ****
  #recovery_target_timeline = '33'		# number or 'latest'
  #
  #---------------------------------------------------------------------------
! # LOG-STREAMING REPLICATION PARAMETERS
  #---------------------------------------------------------------------------
  #
  # When standby_mode is enabled, the PostgreSQL server will work as
--- 88,94 ----
  #recovery_target_timeline = '33'		# number or 'latest'
  #
  #---------------------------------------------------------------------------
! # STANDBY SERVER PARAMETERS
  #---------------------------------------------------------------------------
  #
  # When standby_mode is enabled, the PostgreSQL server will work as