</listitem>
      </varlistentry>
      <varlistentry>
       <term><literal>check_toast</literal></term>
       <listitem>
        <para>
         If true, toasted values are checked against the target relation's
         TOAST table.
        </para>
        <para>
         This option is known to be slow.  Also, if the toast table or its
         index is corrupt, checking it against toast values could conceivably
         crash the server, although in many cases this would just produce an
         error.
        </para>
        <para>
         Defaults to false.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term><literal>skip</literal></term>
       <listitem>
        <para>
         If not <literal>none</literal>, corruption checking skips blocks that
         are marked as all-visible or all-frozen, as specified.
         Valid options are <literal>all-visible</literal>,
         <literal>all-frozen</literal> and <literal>none</literal>.
        </para>
        <para>
         Defaults to <literal>none</literal>.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term><literal>startblock</literal></term>
       <listitem>
        <para>
         If specified, corruption checking begins at the specified block,
         skipping all previous blocks.  It is an error to specify a
         <parameter>startblock</parameter> outside the range of blocks in the
         target table.
        </para>
        <para>
         By default, checking begins at the first block.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term><literal>endblock</literal></term>
       <listitem>
        <para>
         If specified, corruption checking ends at the specified block,
         skipping all remaining blocks.  It is an error to specify an
         <parameter>endblock</parameter> outside the range of blocks in the target
         table.
        </para>
        <para>
         By default, all blocks are checked.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>
     <para>
      For each corruption detected, <function>verify_heapam</function> returns
      a row with the following columns:
     </para>
     <variablelist>
      <varlistentry>
       <term><literal>blkno</literal></term>
       <listitem>
        <para>
         The number of the block containing the corrupt page.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term><literal>offnum</literal></term>
       <listitem>
        <para>
         The OffsetNumber of the corrupt tuple.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term><literal>attnum</literal></term>
       <listitem>
        <para>
         The attribute number of the corrupt column in the tuple, if the
         corruption is specific to a column and not the tuple as a whole.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term><literal>msg</literal></term>
       <listitem>
        <para>
         A message describing the problem detected.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>
    </listitem>
   </varlistentry>
  </variablelist>
 </sect2>

 <sect2 id="amcheck-optional-heapallindexed-verification">
  <title>Optional <parameter>heapallindexed</parameter> Verification</title>
 <para>
  When the <parameter>heapallindexed</parameter> argument to B-Tree
  verification functions is <literal>true</literal>, an additional
  phase of verification is performed against the table associated with
  the target index relation.  This consists of a <quote>dummy</quote>
  <command>CREATE INDEX</command> operation, which checks for the
  presence of all hypothetical new index tuples against a temporary,
  in-memory summarizing structure (this is built when needed during
  the basic first phase of verification).  The summarizing structure
  <quote>fingerprints</quote>