Comparisons of datums of a collatable
     type like <type>text</type> must be immutable (just as all
     comparisons used for B-Tree index scans must be immutable), which
     implies that operating system collation rules must never change.
     Though rare, updates to operating system collation rules can
     cause these issues. More commonly, an inconsistency in the
     collation order between a primary server and a standby server is
     implicated, possibly because the <emphasis>major</emphasis> operating
     system version in use is inconsistent.  Such inconsistencies will
     generally only arise on standby servers, and so can generally
     only be detected on standby servers.
    </para>
    <para>
     If a problem like this arises, it may not affect each individual
     index that is ordered using an affected collation, simply because
     <emphasis>indexed</emphasis> values might happen to have the same
     absolute ordering regardless of the behavioral inconsistency. See
     <xref linkend="locale"/> and <xref linkend="collation"/> for
     further details about how <productname>PostgreSQL</productname> uses
     operating system locales and collations.
    </para>
   </listitem>
   <listitem>
    <para>
     Structural inconsistencies between indexes and the heap relations
     that are indexed (when <parameter>heapallindexed</parameter>
     verification is performed).
    </para>
    <para>
     There is no cross-checking of indexes against their heap relation
     during normal operation.  Symptoms of heap corruption can be subtle.
    </para>
   </listitem>
   <listitem>
    <para>
     Corruption caused by hypothetical undiscovered bugs in the
     underlying <productname>PostgreSQL</productname> access method
     code, sort code, or transaction management code.
    </para>
    <para>
     Automatic verification of the structural integrity of indexes
     plays a role in the general testing of new or proposed
     <productname>PostgreSQL</productname> features that could plausibly allow a
     logical inconsistency to be introduced.  Verification of table
     structure and associated visibility and transaction status
     information plays a similar role.  One obvious testing strategy
     is to call <filename>amcheck</filename> functions continuously
     when running the standard regression tests.  See <xref
     linkend="regress-run"/> for details on running the tests.
    </para>
   </listitem>
   <listitem>
    <para>
     File system or storage subsystem faults when data checksums are
     disabled.
    </para>
    <para>
     Note that <filename>amcheck</filename> examines a page as represented in some
     shared memory buffer at the time of verification if there is only a
     shared buffer hit when accessing the block. Consequently,
     <filename>amcheck</filename> does not necessarily examine data read from the
     file system at the time of verification. Note that when checksums are
     enabled, <filename>amcheck</filename> may raise an error due to a checksum
     failure when a corrupt block is read into a buffer.
    </para>
   </listitem>
   <listitem>
    <para>
     Corruption caused by faulty RAM, or the broader memory subsystem.
    </para>
    <para>
     <productname>PostgreSQL</productname> does not protect against correctable