are:
       <itemizedlist>
        <listitem>
         <para>
          <literal>async</literal>: This standby server is asynchronous.
         </para>
        </listitem>
        <listitem>
         <para>
          <literal>potential</literal>: This standby server is now asynchronous,
          but can potentially become synchronous if one of current
          synchronous ones fails.
         </para>
        </listitem>
        <listitem>
         <para>
          <literal>sync</literal>: This standby server is synchronous.
         </para>
        </listitem>
        <listitem>
         <para>
          <literal>quorum</literal>: This standby server is considered as a candidate
          for quorum standbys.
         </para>
        </listitem>
       </itemizedlist>
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>reply_time</structfield> <type>timestamp with time zone</type>
      </para>
      <para>
       Send time of last reply message received from standby server
      </para></entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <para>
   The lag times reported in the <structname>pg_stat_replication</structname>
   view are measurements of the time taken for recent WAL to be written,
   flushed and replayed and for the sender to know about it.  These times
   represent the commit delay that was (or would have been) introduced by each
   synchronous commit level, if the remote server was configured as a
   synchronous standby.  For an asynchronous standby, the
   <structfield>replay_lag</structfield> column approximates the delay
   before recent transactions became visible to queries.  If the standby
   server has entirely caught up with the sending server and there is no more
   WAL activity, the most recently measured lag times will continue to be
   displayed for a short time and then show NULL.
  </para>

  <para>
   Lag times work automatically for physical replication. Logical decoding
   plugins may optionally emit tracking messages; if they do not, the tracking
   mechanism will simply display NULL lag.
  </para>

  <note>
   <para>
    The reported lag times are not predictions of how long it will take for
    the standby to catch up with the sending server assuming the current
    rate of replay.  Such a system would show similar times while new WAL is
    being generated, but would differ when the sender becomes idle.  In
    particular, when the standby has caught up completely,
    <structname>pg_stat_replication</structname> shows the time taken to
    write, flush and replay the most recent reported WAL location rather than
    zero as some users might expect.  This is consistent with the goal of
    measuring synchronous commit and transaction visibility delays for
    recent write transactions.
    To reduce confusion for users expecting a different model of lag, the
    lag columns revert to NULL after a short time on a fully replayed idle
    system. Monitoring systems should choose whether to represent this
    as missing data, zero or continue to display the last known value.
   </para>
  </note>

 </sect2>

 <sect2 id="monitoring-pg-stat-replication-slots-view">
  <title><structname>pg_stat_replication_slots</structname></title>

  <indexterm>
   <primary>pg_stat_replication_slots</primary>
  </indexterm>

  <para>
   The <structname>pg_stat_replication_slots</structname> view will contain
   one row per logical replication slot, showing statistics about its usage.
  </para>

  <table id="pg-stat-replication-slots-view" xreflabel="pg_stat_replication_slots">
   <title><structname>pg_stat_replication_slots</structname> View</title>
   <tgroup cols="1">
    <thead>
     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
        Column Type
       </para>
       <para>
        Description
      </para></entry>
     </row>
    </thead>

    <tbody>
     <row>
      <entry role="catalog_table_entry"><para