<literal>s3</literal> and <literal>s4</literal> are running, transaction commits will
    wait for replies from at least any two standbys of <literal>s1</literal>,
    <literal>s2</literal> and <literal>s3</literal>. <literal>s4</literal> is an asynchronous
    standby since its name is not in the list.
   </para>
   <para>
    The synchronous states of standby servers can be viewed using
    the <structname>pg_stat_replication</structname> view.
   </para>
   </sect3>

   <sect3 id="synchronous-replication-performance">
    <title>Planning for Performance</title>

   <para>
    Synchronous replication usually requires carefully planned and placed
    standby servers to ensure applications perform acceptably. Waiting
    doesn't utilize system resources, but transaction locks continue to be
    held until the transfer is confirmed. As a result, incautious use of
    synchronous replication will reduce performance for database
    applications because of increased response times and higher contention.
   </para>

   <para>
    <productname>PostgreSQL</productname> allows the application developer
    to specify the durability level required via replication. This can be
    specified for the system overall, though it can also be specified for
    specific users or connections, or even individual transactions.
   </para>

   <para>
    For example, an application workload might consist of:
    10% of changes are important customer details, while
    90% of changes are less important data that the business can more
    easily survive if it is lost, such as chat messages between users.
   </para>

   <para>
    With synchronous replication options specified at the application level
    (on the primary) we can offer synchronous replication for the most
    important changes, without slowing down the bulk of the total workload.
    Application level options are an important and practical tool for allowing
    the benefits of synchronous replication for high performance applications.
   </para>

   <para>
    You should consider that the network bandwidth must be higher than
    the rate of generation of WAL data.
   </para>

   </sect3>

   <sect3 id="synchronous-replication-ha">
    <title>Planning for High Availability</title>

   <para>
    <varname>synchronous_standby_names</varname> specifies the number and
    names of synchronous standbys that transaction commits made when
    <varname>synchronous_commit</varname> is set to <literal>on</literal>,
    <literal>remote_apply</literal> or <literal>remote_write</literal> will wait for
    responses from. Such transaction commits may never be completed
    if any one of the synchronous standbys should crash.
   </para>

   <para>
    The best solution for high availability is to ensure you keep as many
    synchronous standbys as requested. This can be achieved by naming multiple
    potential synchronous standbys using <varname>synchronous_standby_names</varname>.
   </para>

   <para>
    In a 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