<entry><literal>IO</literal></entry>
      <entry>The server process is waiting for an I/O operation to complete.
       <literal>wait_event</literal> will identify the specific wait point;
       see <xref linkend="wait-event-io-table"/>.
      </entry>
     </row>
     <row>
      <entry><literal>IPC</literal></entry>
      <entry>The server process is waiting for some interaction with
       another server process.  <literal>wait_event</literal> will
       identify the specific wait point;
       see <xref linkend="wait-event-ipc-table"/>.
      </entry>
     </row>
     <row>
      <entry><literal>Lock</literal></entry>
      <entry>The server process is waiting for a heavyweight lock.
       Heavyweight locks, also known as lock manager locks or simply locks,
       primarily protect SQL-visible objects such as tables.  However,
       they are also used to ensure mutual exclusion for certain internal
       operations such as relation extension.  <literal>wait_event</literal>
       will identify the type of lock awaited;
       see <xref linkend="wait-event-lock-table"/>.
      </entry>
     </row>
     <row>
      <entry><literal>LWLock</literal></entry>
      <entry> The server process is waiting for a lightweight lock.
       Most such locks protect a particular data structure in shared memory.
       <literal>wait_event</literal> will contain a name identifying the purpose
       of the lightweight lock.  (Some locks have specific names; others
       are part of a group of locks each with a similar purpose.)
       See <xref linkend="wait-event-lwlock-table"/>.
      </entry>
     </row>
     <row>
      <entry><literal>Timeout</literal></entry>
      <entry>The server process is waiting for a timeout
       to expire.  <literal>wait_event</literal> will identify the specific wait
       point; see <xref linkend="wait-event-timeout-table"/>.
      </entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  &wait_event_types;

   <para>
     Here are examples of how wait events can be viewed:

<programlisting>
SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;
 pid  | wait_event_type | wait_event
------+-----------------+------------
 2540 | Lock            | relation
 6644 | LWLock          | ProcArray
(2 rows)
</programlisting>

<programlisting>
SELECT a.pid, a.wait_event, w.description
  FROM pg_stat_activity a JOIN
       pg_wait_events w ON (a.wait_event_type = w.type AND
                            a.wait_event = w.name)
  WHERE a.wait_event is NOT NULL and a.state = 'active';
-[ RECORD 1 ]------------------------------------------------------&zwsp;------------
pid         | 686674
wait_event  | WALInitSync
description | Waiting for a newly initialized WAL file to reach durable storage
</programlisting>
   </para>

   <note>
    <para>
     Extensions can add <literal>Extension</literal>,
     <literal>InjectionPoint</literal>, and <literal>LWLock</literal> events
     to the lists shown in <xref linkend="wait-event-extension-table"/> and
     <xref linkend="wait-event-lwlock-table"/>. In some cases, the name
     of an <literal>LWLock</literal> assigned by an extension will not be
     available in all server processes.  It might be reported as just
     <quote><literal>extension</literal></quote> rather than the
     extension-assigned name.
    </para>
   </note>
 </sect2>

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

  <indexterm>
   <primary>pg_stat_replication</primary>
  </indexterm>

   <para>
   The <structname>pg_stat_replication</structname> view will contain one row
   per WAL sender process, showing statistics about replication to that
   sender's connected standby server.  Only directly connected standbys are
   listed; no information is available about downstream standby servers.
  </para>

  <table id="pg-stat-replication-view" xreflabel="pg_stat_replication">
   <title><structname>pg_stat_replication</structname>