<literal>startup</literal>, <literal>walreceiver</literal>,
       <literal>walsender</literal>, <literal>walwriter</literal> and
       <literal>walsummarizer</literal>.
       In addition, background workers registered by extensions may have
       additional types.
      </para></entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <note>
   <para>
    The <structfield>wait_event</structfield> and <structfield>state</structfield> columns are
    independent.  If a backend is in the <literal>active</literal> state,
    it may or may not be <literal>waiting</literal> on some event.  If the state
    is <literal>active</literal> and <structfield>wait_event</structfield> is non-null, it
    means that a query is being executed, but is being blocked somewhere
    in the system.  To keep the reporting overhead low, the system does not
    attempt to synchronize different aspects of activity data for a backend.
    As a result, ephemeral discrepancies may exist between the view's columns.
   </para>
  </note>

  <table id="wait-event-table">
   <title>Wait Event Types</title>
   <tgroup cols="2">
    <thead>
     <row>
      <entry>Wait Event Type</entry>
      <entry>Description</entry>
     </row>
    </thead>

    <tbody>
     <row>
      <entry><literal>Activity</literal></entry>
      <entry>The server process is idle.  This event type indicates a process
       waiting for activity in its main processing loop.
       <literal>wait_event</literal> will identify the specific wait point;
       see <xref linkend="wait-event-activity-table"/>.
      </entry>
     </row>
     <row>
      <entry><literal>BufferPin</literal></entry>
      <entry>The server process is waiting for exclusive access to
       a data buffer.  Buffer pin waits can be protracted if
       another process holds an open cursor that last read data from the
       buffer in question. See <xref linkend="wait-event-bufferpin-table"/>.
      </entry>
     </row>
     <row>
      <entry><literal>Client</literal></entry>
      <entry>The server process is waiting for activity on a socket
       connected to a user application.  Thus, the server expects something
       to happen that is independent of its internal processes.
       <literal>wait_event</literal> will identify the specific wait point;
       see <xref linkend="wait-event-client-table"/>.
      </entry>
     </row>
     <row>
      <entry><literal>Extension</literal></entry>
      <entry>The server process is waiting for some condition defined by an
       extension module.
       See <xref linkend="wait-event-extension-table"/>.
      </entry>
     </row>
     <row>
      <entry><literal>InjectionPoint</literal></entry>
      <entry>The server process is waiting for an injection point to reach an
       outcome defined in a test.  See
       <xref linkend="xfunc-addin-injection-points"/> for more details.  This
       type has no predefined wait points.
      </entry>
     </row>
     <row>
      <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