this
       option can be used to skip them.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><option>--on-error-stop</option></term>
     <listitem>
      <para>
       After reporting all corruptions on the first page of a table where
       corruption is found, stop processing that table relation and move on
       to the next table or index.
      </para>
      <para>
       Note that index checking always stops after the first corrupt page.
       This option only has meaning relative to table relations.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><option>--skip=<replaceable class="parameter">option</replaceable></option></term>
     <listitem>
      <para>
       If <literal>all-frozen</literal> is given, table corruption checks
       will skip over pages in all tables that are marked as all frozen.
      </para>
      <para>
       If <literal>all-visible</literal> is given, table corruption checks
       will skip over pages in all tables that are marked as all visible.
      </para>
      <para>
       By default, no pages are skipped.  This can be specified as
       <literal>none</literal>, but since this is the default, it need not be
       mentioned.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><option>--startblock=<replaceable class="parameter">block</replaceable></option></term>
     <listitem>
      <para>
       Start checking at the specified block number. An error will occur if
       the table relation being checked has fewer than this number of blocks.
       This option does not apply to indexes, and is probably only useful
       when checking a single table relation. See <literal>--endblock</literal>
       for further caveats.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><option>--endblock=<replaceable class="parameter">block</replaceable></option></term>
     <listitem>
      <para>
       End checking at the specified block number.  An error will occur if the
       table relation being checked has fewer than this number of blocks.
       This option does not apply to indexes, and is probably only useful when
       checking a single table relation. If both a regular table and a toast
       table are checked, this option will apply to both, but higher-numbered
       toast blocks may still be accessed while validating toast pointers,
       unless that is suppressed using
       <option>--exclude-toast-pointers</option>.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   The following command-line options control checking of B-tree indexes:

   <variablelist>
    <varlistentry>
     <term><option>--checkunique</option></term>
     <listitem>
      <para>
       For each index with unique constraint checked, verify that no more than
       one among duplicate entries is visible in the index using <xref linkend="amcheck"/>'s
       <option>checkunique</option> option.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><option>--heapallindexed</option></term>
     <listitem>
      <para>
       For each index checked, verify the presence of all heap tuples as index
       tuples in the index using <xref linkend="amcheck"/>'s
       <option>heapallindexed</option> option.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><option>--parent-check</option></term>
     <listitem>
      <para>
       For each btree index checked, use <xref linkend="amcheck"/>'s
       <function>bt_index_parent_check</function> function, which performs
       additional checks of parent/child relationships during index checking.
      </para>
      <para>
       The default is to use <application>amcheck</application>'s
       <function>bt_index_check</function> function, but note that use of the
       <option>--rootdescend</option> option implicitly selects
       <function>bt_index_parent_check</function>.