linkend="runtime-config-wal-settings"/> and
    <xref linkend="runtime-config-replication-primary"/>.)
    This configuration will cause each commit to wait for
    confirmation that the standby has written the commit record to durable
    storage.
    <varname>synchronous_commit</varname> can be set by individual
    users, so it can be configured in the configuration file, for particular
    users or databases, or dynamically by applications, in order to control
    the durability guarantee on a per-transaction basis.
   </para>

   <para>
    After a commit record has been written to disk on the primary, the
    WAL record is then sent to the standby. The standby sends reply
    messages each time a new batch of WAL data is written to disk, unless
    <varname>wal_receiver_status_interval</varname> is set to zero on the standby.
    In the case that <varname>synchronous_commit</varname> is set to
    <literal>remote_apply</literal>, the standby sends reply messages when the commit
    record is replayed, making the transaction visible.
    If the standby is chosen as a synchronous standby, according to the setting
    of <varname>synchronous_standby_names</varname> on the primary, the reply
    messages from that standby will be considered along with those from other
    synchronous standbys to decide when to release transactions waiting for
    confirmation that the commit record has been received. These parameters
    allow the administrator to specify which standby servers should be
    synchronous standbys. Note that the configuration of synchronous
    replication is mainly on the primary. Named standbys must be directly
    connected to the primary; the primary knows nothing about downstream
    standby servers using cascaded replication.
   </para>

   <para>
    Setting <varname>synchronous_commit</varname> to <literal>remote_write</literal> will
    cause each commit to wait for confirmation that the standby has received
    the commit record and written it out to its own operating system, but not
    for the data to be flushed to disk on the standby.  This
    setting provides a weaker guarantee of durability than <literal>on</literal>
    does: the standby could lose the data in the event of an operating system
    crash, though not a <productname>PostgreSQL</productname> crash.
    However, it's a useful setting in practice
    because it can decrease the response time for the transaction.
    Data loss could only occur if both the primary and the standby crash and
    the database of the primary gets corrupted at the same time.
   </para>

   <para>
    Setting <varname>synchronous_commit</varname> to <literal>remote_apply</literal> will
    cause each commit to wait until the current synchronous standbys report
    that they have replayed the transaction, making it visible to user
    queries.  In simple cases, this allows for load balancing with causal
    consistency.
   </para>

   <para>
    Users will stop waiting if a fast shutdown is requested.  However, as
    when using asynchronous replication, the server will not fully
    shutdown until all outstanding WAL records are transferred to the currently
    connected standby servers.
   </para>

   </sect3>

   <sect3 id="synchronous-replication-multiple-standbys">
    <title>Multiple Synchronous Standbys</title>

   <para>
    Synchronous replication supports one or more synchronous standby servers;
    transactions will wait until all the standby servers which are considered
    as synchronous confirm receipt of their data. The number of synchronous
    standbys that transactions must wait for replies from is specified in
    <varname>synchronous_standby_names</varname>. This parameter also specifies
    a list of standby names and the method (<literal>FIRST</literal> and
    <literal>ANY</literal>) to choose synchronous standbys from the listed ones.
   </para>
   <para>
    The method <literal>FIRST</literal> specifies a priority-based synchronous