loss is proportional to the replication delay at the time of
    failover.
   </para>

   <para>
    Synchronous replication offers the ability to confirm that all changes
    made by a transaction have been transferred to one or more synchronous
    standby servers. This extends that standard level of durability
    offered by a transaction commit. This level of protection is referred
    to as 2-safe replication in computer science theory, and group-1-safe
    (group-safe and 1-safe) when <varname>synchronous_commit</varname> is set to
    <literal>remote_write</literal>.
   </para>

   <para>
    When requesting synchronous replication, each commit of a
    write transaction will wait until confirmation is
    received that the commit has been written to the write-ahead log on disk
    of both the primary and standby server. The only possibility that data
    can be lost is if both the primary and the standby suffer crashes at the
    same time. This can provide a much higher level of durability, though only
    if the sysadmin is cautious about the placement and management of the two
    servers.  Waiting for confirmation increases the user's confidence that the
    changes will not be lost in the event of server crashes but it also
    necessarily increases the response time for the requesting transaction.
    The minimum wait time is the round-trip time between primary and standby.
   </para>

   <para>
    Read-only transactions and transaction rollbacks need not wait for
    replies from standby servers. Subtransaction commits do not wait for
    responses from standby servers, only top-level commits. Long
    running actions such as data loading or index building do not wait
    until the very final commit message. All two-phase commit actions
    require commit waits, including both prepare and commit.
   </para>

   <para>
    A synchronous standby can be a physical replication standby or a logical
    replication subscriber.  It can also be any other physical or logical WAL
    replication stream consumer that knows how to send the appropriate
    feedback messages.  Besides the built-in physical and logical replication
    systems, this includes special programs such
    as <command>pg_receivewal</command> and <command>pg_recvlogical</command>
    as well as some third-party replication systems and custom programs.
    Check the respective documentation for details on synchronous replication
    support.
   </para>

   <sect3 id="synchronous-replication-config">
    <title>Basic Configuration</title>

   <para>
    Once streaming replication has been configured, configuring synchronous
    replication requires only one additional configuration step:
    <xref linkend="guc-synchronous-standby-names"/> must be set to
    a non-empty value.  <varname>synchronous_commit</varname> must also be set to
    <literal>on</literal>, but since this is the default value, typically no change is
    required.  (See <xref 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