priority-based synchronous replication, the standbys whose names
    appear earlier in the list will be used as synchronous standbys.
    Standbys listed after these will take over the role of synchronous standby
    if one of current ones should fail.
   </para>

   <para>
    In a quorum-based synchronous replication, all the standbys appearing
    in the list will be used as candidates for synchronous standbys.
    Even if one of them should fail, the other standbys will keep performing
    the role of candidates of synchronous standby.
   </para>

   <para>
    When a standby first attaches to the primary, it will not yet be properly
    synchronized. This is described as <literal>catchup</literal> mode. Once
    the lag between standby and primary reaches zero for the first time
    we move to real-time <literal>streaming</literal> 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</literal> state.
    This state can be viewed using
    the <structname>pg_stat_replication</structname> view.
   </para>

   <para>
    If primary restarts while commits are waiting for acknowledgment, those
    waiting transactions will be marked fully committed once the primary
    database recovers.
    There is no way to be certain that all standbys have received all
    outstanding WAL data at time of the crash of the primary. Some
    transactions may not show as committed on the standby, even though
    they show as committed on the primary. The guarantee we offer is that
    the application will not receive explicit acknowledgment of the
    successful commit of a transaction until the WAL data is known to be
    safely received by all the synchronous standbys.
   </para>

   <para>
    If you really cannot keep as many synchronous standbys as requested
    then you should decrease the number of synchronous standbys that
    transaction commits must wait for responses from
    in <varname>synchronous_standby_names</varname> (or disable it) and
    reload the configuration file on the primary server.
   </para>

   <para>
    If the primary is isolated from remaining standby servers you should
    fail over to the best candidate of those other remaining standby servers.
   </para>

   <para>
    If you need to re-create a standby server while transactions are
    waiting, make sure that the functions <function>pg_backup_start()</function>
    and <function>pg_backup_stop()</function> are run in a session with
    <varname>synchronous_commit</varname> = <literal>off</literal>, otherwise those
    requests will wait forever for the standby to appear.
   </para>

   </sect3>
  </sect2>

  <sect2 id="continuous-archiving-in-standby">
   <title>Continuous Archiving in Standby</title>

   <indexterm>
     <primary>continuous archiving</primary>
     <secondary>in standby</secondary>
   </indexterm>

   <para>
     When continuous WAL archiving is used in a standby, there are two
     different scenarios: the WAL archive can be shared between the primary
     and the standby, or the standby can have its own WAL archive. When
     the standby has its own WAL archive, set <varname>archive_mode</varname>
     to <literal>always</literal>, and the standby will call the archive
     command for every WAL segment it receives, whether it's by restoring
     from the archive or by streaming replication. The shared archive can
     be handled similarly, but the <varname>archive_command</varname> or <varname>archive_library</varname> must
     test if the file being archived exists already, and if the existing file
     has identical contents. This requires more care in the
     <varname>archive_command</varname> or <varname>archive_library</varname>, as it must
     be careful