Home Explore Blog CI



postgresql

9th chunk of `doc/src/sgml/amcheck.sgml`
14e10ce08e43a178280ed09ed2798f9004f9f3d34b921a690000000100000c5b
 ECC memory is typically only immune to
     single-bit errors, and should not be assumed to provide
     <emphasis>absolute</emphasis> protection against failures that
     result in memory corruption.
    </para>
    <para>
     When <parameter>heapallindexed</parameter> verification is
     performed, there is generally a greatly increased chance of
     detecting single-bit errors, since strict binary equality is
     tested, and the indexed attributes within the heap are tested.
    </para>
   </listitem>
  </itemizedlist>
 </para>

 <para>
  Structural corruption can happen due to faulty storage hardware, or
  relation files being overwritten or modified by unrelated software.
  This kind of corruption can also be detected with
  <link linkend="checksums"><application>data page
  checksums</application></link>.
 </para>

 <para>
  Relation pages which are correctly formatted, internally consistent, and
  correct relative to their own internal checksums may still contain
  logical corruption.  As such, this kind of corruption cannot be detected
  with <application>checksums</application>.  Examples include toasted
  values in the main table which lack a corresponding entry in the toast
  table, and tuples in the main table with a Transaction ID that is older
  than the oldest valid Transaction ID in the database or cluster.
 </para>

 <para>
  Multiple causes of logical corruption have been observed in production
  systems, including bugs in the <productname>PostgreSQL</productname>
  server software, faulty and ill-conceived backup and restore tools, and
  user error.
 </para>

 <para>
  Corrupt relations are most concerning in live production environments,
  precisely the same environments where high risk activities are least
  welcome.  For this reason, <function>verify_heapam</function> has been
  designed to diagnose corruption without undue risk.  It cannot guard
  against all causes of backend crashes, as even executing the calling
  query could be unsafe on a badly corrupted system.   Access to <link
  linkend="catalogs-overview">catalog tables</link> is performed and could
  be problematic if the catalogs themselves are corrupted.
 </para>

 <para>
  In general, <filename>amcheck</filename> can only prove the presence of
  corruption; it cannot prove its absence.
 </para>

 </sect2>
 <sect2 id="amcheck-repairing-corruption">
  <title>Repairing Corruption</title>
 <para>
  No error concerning corruption raised by <filename>amcheck</filename> should
  ever be a false positive.  <filename>amcheck</filename> raises
  errors in the event of conditions that, by definition, should never
  happen, and so careful analysis of <filename>amcheck</filename>
  errors is often required.
 </para>
 <para>
  There is no general method of repairing problems that
  <filename>amcheck</filename> detects.  An explanation for the root cause of
  an invariant violation should be sought.  <xref
  linkend="pageinspect"/> may play a useful role in diagnosing
  corruption that <filename>amcheck</filename> detects.  A <command>REINDEX</command>
  may not be effective in repairing corruption.
 </para>

 </sect2>

</sect1>

Title: Detecting and Repairing Data Corruption in PostgreSQL
Summary
Data corruption in PostgreSQL can be detected using tools like amcheck, which can identify issues such as logical corruption, but cannot prove the absence of corruption. Repairing corruption is a complex process that requires careful analysis of error messages and may involve using additional tools like pageinspect, but there is no general method for repairing problems detected by amcheck.