<para>
       Time of the most recent successful archive operation
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>failed_count</structfield> <type>bigint</type>
      </para>
      <para>
       Number of failed attempts for archiving WAL files
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>last_failed_wal</structfield> <type>text</type>
      </para>
      <para>
       Name of the WAL file of the most recent failed archival operation
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>last_failed_time</structfield> <type>timestamp with time zone</type>
      </para>
      <para>
       Time of the most recent failed archival operation
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>stats_reset</structfield> <type>timestamp with time zone</type>
      </para>
      <para>
       Time at which these statistics were last reset
      </para></entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <para>
    Normally, WAL files are archived in order, oldest to newest, but that is
    not guaranteed, and does not hold under special circumstances like when
    promoting a standby or after crash recovery. Therefore it is not safe to
    assume that all files older than
    <structfield>last_archived_wal</structfield> have also been successfully
    archived.
  </para>
 </sect2>

 <sect2 id="monitoring-pg-stat-io-view">
  <title><structname>pg_stat_io</structname></title>

  <indexterm>
   <primary>pg_stat_io</primary>
  </indexterm>

  <para>
   The <structname>pg_stat_io</structname> view will contain one row for each
   combination of backend type, target I/O object, and I/O context, showing
   cluster-wide I/O statistics. Combinations which do not make sense are
   omitted.
  </para>

  <para>
   Currently, I/O on relations (e.g. tables, indexes) and WAL activity are
   tracked. However, relation I/O which bypasses shared buffers
   (e.g. when moving a table from one tablespace to another) is currently
   not tracked.
  </para>

  <table id="pg-stat-io-view" xreflabel="pg_stat_io">
   <title><structname>pg_stat_io</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 role="column_definition">
        <structfield>backend_type</structfield> <type>text</type>
       </para>
       <para>
        Type of backend (e.g. background worker, autovacuum worker). See <link
        linkend="monitoring-pg-stat-activity-view">
        <structname>pg_stat_activity</structname></link> for more information
        on <varname>backend_type</varname>s. Some
        <varname>backend_type</varname>s do not accumulate I/O operation
        statistics and will not be included in the view.
       </para>
      </entry>
     </row>

     <row>
      <entry role="catalog_table_entry">
       <para role="column_definition">
        <structfield>object</structfield> <type>text</type>
       </para>
       <para>
        Target object of an I/O operation. Possible values are:
       <itemizedlist>
        <listitem>
         <para>
          <literal>relation</literal>: Permanent relations.
         </para>
        </listitem>
        <listitem>
         <para>
          <literal>temp relation</literal>: Temporary relations.
         </para>
        </listitem>
        <listitem>
         <para>
          <literal>wal</literal>: Write Ahead Logs.
         </para>
        </listitem>
       </itemizedlist>