Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
Vērot 1
Pievienot zvaigznīti 0
Vikivietne 捐赠
gooderp18绿色标准版
Nevar pievienot vairāk kā 25 tēmas Tēmai ir jāsākas ar burtu vai ciparu, tā var saturēt domu zīmes ('-') un var būt līdz 35 simboliem gara.
Atzars: master
Atzari Tagi
${ item.name }
Izveidot atzaru ${ searchTerm }
no 'master'
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/amcheck.html

250 rindas
19KB
Neapstrādāts Patstāvīgā saite Vainot Vēsture 

  1. <?xml version="1.0" encoding="UTF-8" standalone="no"?>

  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>F.2. amcheck</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="prev" href="adminpack.html" title="F.1. adminpack" /><link rel="next" href="auth-delay.html" title="F.3. auth_delay" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">F.2. amcheck</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="adminpack.html" title="F.1. adminpack">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="contrib.html" title="Appendix F. Additional Supplied Modules">Up</a></td><th width="60%" align="center">Appendix F. Additional Supplied Modules</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="auth-delay.html" title="F.3. auth_delay">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="AMCHECK"><div class="titlepage"><div><div><h2 class="title" style="clear: both">F.2. amcheck</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="amcheck.html#id-1.11.7.11.7">F.2.1. Functions</a></span></dt><dt><span class="sect2"><a href="amcheck.html#id-1.11.7.11.8">F.2.2. Optional <em class="parameter"><code>heapallindexed</code></em> Verification</a></span></dt><dt><span class="sect2"><a href="amcheck.html#id-1.11.7.11.9">F.2.3. Using <code class="filename">amcheck</code> Effectively</a></span></dt><dt><span class="sect2"><a href="amcheck.html#id-1.11.7.11.10">F.2.4. Repairing Corruption</a></span></dt></dl></div><a id="id-1.11.7.11.2" class="indexterm"></a><p>

  3.   The <code class="filename">amcheck</code> module provides functions that allow you to

  4.   verify the logical consistency of the structure of relations.  If the

  5.   structure appears to be valid, no error is raised.

  6.  </p><p>

  7.   The functions verify various <span class="emphasis"><em>invariants</em></span> in the

  8.   structure of the representation of particular relations.  The

  9.   correctness of the access method functions behind index scans and

  10.   other important operations relies on these invariants always

  11.   holding.  For example, certain functions verify, among other things,

  12.   that all B-Tree pages have items in <span class="quote">“<span class="quote">logical</span>”</span> order (e.g.,

  13.   for B-Tree indexes on <code class="type">text</code>, index tuples should be in

  14.   collated lexical order).  If that particular invariant somehow fails

  15.   to hold, we can expect binary searches on the affected page to

  16.   incorrectly guide index scans, resulting in wrong answers to SQL

  17.   queries.

  18.  </p><p>

  19.   Verification is performed using the same procedures as those used by

  20.   index scans themselves, which may be user-defined operator class

  21.   code.  For example, B-Tree index verification relies on comparisons

  22.   made with one or more B-Tree support function 1 routines.  See <a class="xref" href="xindex.html#XINDEX-SUPPORT" title="37.16.3. Index Method Support Routines">Section 37.16.3</a> for details of operator class support

  23.   functions.

  24.  </p><p>

  25.   <code class="filename">amcheck</code> functions may only be used by superusers.

  26.  </p><div class="sect2" id="id-1.11.7.11.7"><div class="titlepage"><div><div><h3 class="title">F.2.1. Functions</h3></div></div></div><div class="variablelist"><dl class="variablelist"><dt><span class="term">

  27.      <code class="function">bt_index_check(index regclass, heapallindexed boolean) returns void</code>

  28.      <a id="id-1.11.7.11.7.2.1.1.2" class="indexterm"></a>

  29.     </span></dt><dd><p>

  30.       <code class="function">bt_index_check</code> tests that its target, a

  31.       B-Tree index, respects a variety of invariants.  Example usage:

  32. </p><pre class="screen">

  33. test=# SELECT bt_index_check(index =&gt; c.oid, heapallindexed =&gt; i.indisunique),

  34.                c.relname,

  35.                c.relpages

  36. FROM pg_index i

  37. JOIN pg_opclass op ON i.indclass[0] = op.oid

  38. JOIN pg_am am ON op.opcmethod = am.oid

  39. JOIN pg_class c ON i.indexrelid = c.oid

  40. JOIN pg_namespace n ON c.relnamespace = n.oid

  41. WHERE am.amname = 'btree' AND n.nspname = 'pg_catalog'

  42. -- Don't check temp tables, which may be from another session:

  43. AND c.relpersistence != 't'

  44. -- Function may throw an error when this is omitted:

  45. AND c.relkind = 'i' AND i.indisready AND i.indisvalid

  46. ORDER BY c.relpages DESC LIMIT 10;

  47.  bt_index_check |             relname             | relpages 

  48. ----------------+---------------------------------+----------

  49.                 | pg_depend_reference_index       |       43

  50.                 | pg_depend_depender_index        |       40

  51.                 | pg_proc_proname_args_nsp_index  |       31

  52.                 | pg_description_o_c_o_index      |       21

  53.                 | pg_attribute_relid_attnam_index |       14

  54.                 | pg_proc_oid_index               |       10

  55.                 | pg_attribute_relid_attnum_index |        9

  56.                 | pg_amproc_fam_proc_index        |        5

  57.                 | pg_amop_opr_fam_index           |        5

  58.                 | pg_amop_fam_strat_index         |        5

  59. (10 rows)

  60. </pre><p>

  61.       This example shows a session that performs verification of the

  62.       10 largest catalog indexes in the database <span class="quote">“<span class="quote">test</span>”</span>.

  63.       Verification of the presence of heap tuples as index tuples is

  64.       requested for the subset that are unique indexes.  Since no

  65.       error is raised, all indexes tested appear to be logically

  66.       consistent.  Naturally, this query could easily be changed to

  67.       call <code class="function">bt_index_check</code> for every index in the

  68.       database where verification is supported.

  69.      </p><p>

  70.       <code class="function">bt_index_check</code> acquires an <code class="literal">AccessShareLock</code>

  71.       on the target index and the heap relation it belongs to. This lock mode

  72.       is the same lock mode acquired on relations by simple

  73.       <code class="literal">SELECT</code> statements.

  74.       <code class="function">bt_index_check</code> does not verify invariants

  75.       that span child/parent relationships, but will verify the

  76.       presence of all heap tuples as index tuples within the index

  77.       when <em class="parameter"><code>heapallindexed</code></em> is

  78.       <code class="literal">true</code>.  When a routine, lightweight test for

  79.       corruption is required in a live production environment, using

  80.       <code class="function">bt_index_check</code> often provides the best

  81.       trade-off between thoroughness of verification and limiting the

  82.       impact on application performance and availability.

  83.      </p></dd><dt><span class="term">

  84.      <code class="function">bt_index_parent_check(index regclass, heapallindexed boolean, rootdescend boolean) returns void</code>

  85.      <a id="id-1.11.7.11.7.2.2.1.2" class="indexterm"></a>

  86.     </span></dt><dd><p>

  87.       <code class="function">bt_index_parent_check</code> tests that its

  88.       target, a B-Tree index, respects a variety of invariants.

  89.       Optionally, when the <em class="parameter"><code>heapallindexed</code></em>

  90.       argument is <code class="literal">true</code>, the function verifies the

  91.       presence of all heap tuples that should be found within the

  92.       index, and that there are no missing downlinks in the index

  93.       structure.  When the optional <em class="parameter"><code>rootdescend</code></em>

  94.       argument is <code class="literal">true</code>, verification re-finds

  95.       tuples on the leaf level by performing a new search from the

  96.       root page for each tuple.  The checks that can be performed by

  97.       <code class="function">bt_index_parent_check</code> are a superset of the

  98.       checks that can be performed by <code class="function">bt_index_check</code>.

  99.       <code class="function">bt_index_parent_check</code> can be thought of as

  100.       a more thorough variant of <code class="function">bt_index_check</code>:

  101.       unlike <code class="function">bt_index_check</code>,

  102.       <code class="function">bt_index_parent_check</code> also checks

  103.       invariants that span parent/child relationships.

  104.       <code class="function">bt_index_parent_check</code> follows the general

  105.       convention of raising an error if it finds a logical

  106.       inconsistency or other problem.

  107.      </p><p>

  108.       A <code class="literal">ShareLock</code> is required on the target index by

  109.       <code class="function">bt_index_parent_check</code> (a

  110.       <code class="literal">ShareLock</code> is also acquired on the heap relation).

  111.       These locks prevent concurrent data modification from

  112.       <code class="command">INSERT</code>, <code class="command">UPDATE</code>, and <code class="command">DELETE</code>

  113.       commands.  The locks also prevent the underlying relation from

  114.       being concurrently processed by <code class="command">VACUUM</code>, as well as

  115.       all other utility commands.  Note that the function holds locks

  116.       only while running, not for the entire transaction.

  117.      </p><p>

  118.       <code class="function">bt_index_parent_check</code>'s additional

  119.       verification is more likely to detect various pathological

  120.       cases.  These cases may involve an incorrectly implemented

  121.       B-Tree operator class used by the index that is checked, or,

  122.       hypothetically, undiscovered bugs in the underlying B-Tree index

  123.       access method code.  Note that

  124.       <code class="function">bt_index_parent_check</code> cannot be used when

  125.       Hot Standby mode is enabled (i.e., on read-only physical

  126.       replicas), unlike <code class="function">bt_index_check</code>.

  127.      </p></dd></dl></div></div><div class="sect2" id="id-1.11.7.11.8"><div class="titlepage"><div><div><h3 class="title">F.2.2. Optional <em class="parameter"><code>heapallindexed</code></em> Verification</h3></div></div></div><p>

  128.   When the <em class="parameter"><code>heapallindexed</code></em> argument to

  129.   verification functions is <code class="literal">true</code>, an additional

  130.   phase of verification is performed against the table associated with

  131.   the target index relation.  This consists of a <span class="quote">“<span class="quote">dummy</span>”</span>

  132.   <code class="command">CREATE INDEX</code> operation, which checks for the

  133.   presence of all hypothetical new index tuples against a temporary,

  134.   in-memory summarizing structure (this is built when needed during

  135.   the basic first phase of verification).  The summarizing structure

  136.   <span class="quote">“<span class="quote">fingerprints</span>”</span> every tuple found within the target

  137.   index.  The high level principle behind

  138.   <em class="parameter"><code>heapallindexed</code></em> verification is that a new

  139.   index that is equivalent to the existing, target index must only

  140.   have entries that can be found in the existing structure.

  141.  </p><p>

  142.   The additional <em class="parameter"><code>heapallindexed</code></em> phase adds

  143.   significant overhead: verification will typically take several times

  144.   longer.  However, there is no change to the relation-level locks

  145.   acquired when <em class="parameter"><code>heapallindexed</code></em> verification is

  146.   performed.

  147.  </p><p>

  148.   The summarizing structure is bound in size by

  149.   <code class="varname">maintenance_work_mem</code>.  In order to ensure that

  150.   there is no more than a 2% probability of failure to detect an

  151.   inconsistency for each heap tuple that should be represented in the

  152.   index, approximately 2 bytes of memory are needed per tuple.  As

  153.   less memory is made available per tuple, the probability of missing

  154.   an inconsistency slowly increases.  This approach limits the

  155.   overhead of verification significantly, while only slightly reducing

  156.   the probability of detecting a problem, especially for installations

  157.   where verification is treated as a routine maintenance task.  Any

  158.   single absent or malformed tuple has a new opportunity to be

  159.   detected with each new verification attempt.

  160.  </p></div><div class="sect2" id="id-1.11.7.11.9"><div class="titlepage"><div><div><h3 class="title">F.2.3. Using <code class="filename">amcheck</code> Effectively</h3></div></div></div><p>

  161.   <code class="filename">amcheck</code> can be effective at detecting various types of

  162.   failure modes that <a class="link" href="app-initdb.html#APP-INITDB-DATA-CHECKSUMS"><span class="application">data page

  163.   checksums</span></a> will always fail to catch.  These include:

  164. 

  165.   </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>

  166.      Structural inconsistencies caused by incorrect operator class

  167.      implementations.

  168.     </p><p>

  169.      This includes issues caused by the comparison rules of operating

  170.      system collations changing. Comparisons of datums of a collatable

  171.      type like <code class="type">text</code> must be immutable (just as all

  172.      comparisons used for B-Tree index scans must be immutable), which

  173.      implies that operating system collation rules must never change.

  174.      Though rare, updates to operating system collation rules can

  175.      cause these issues. More commonly, an inconsistency in the

  176.      collation order between a master server and a standby server is

  177.      implicated, possibly because the <span class="emphasis"><em>major</em></span> operating

  178.      system version in use is inconsistent.  Such inconsistencies will

  179.      generally only arise on standby servers, and so can generally

  180.      only be detected on standby servers.

  181.     </p><p>

  182.      If a problem like this arises, it may not affect each individual

  183.      index that is ordered using an affected collation, simply because

  184.      <span class="emphasis"><em>indexed</em></span> values might happen to have the same

  185.      absolute ordering regardless of the behavioral inconsistency. See

  186.      <a class="xref" href="locale.html" title="23.1. Locale Support">Section 23.1</a> and <a class="xref" href="collation.html" title="23.2. Collation Support">Section 23.2</a> for

  187.      further details about how <span class="productname">PostgreSQL</span> uses

  188.      operating system locales and collations.

  189.     </p></li><li class="listitem"><p>

  190.      Structural inconsistencies between indexes and the heap relations

  191.      that are indexed (when <em class="parameter"><code>heapallindexed</code></em>

  192.      verification is performed).

  193.     </p><p>

  194.      There is no cross-checking of indexes against their heap relation

  195.      during normal operation.  Symptoms of heap corruption can be subtle.

  196.     </p></li><li class="listitem"><p>

  197.      Corruption caused by hypothetical undiscovered bugs in the

  198.      underlying <span class="productname">PostgreSQL</span> access method

  199.      code, sort code, or transaction management code.

  200.     </p><p>

  201.      Automatic verification of the structural integrity of indexes

  202.      plays a role in the general testing of new or proposed

  203.      <span class="productname">PostgreSQL</span> features that could plausibly allow a

  204.      logical inconsistency to be introduced.  Verification of table

  205.      structure and associated visibility and transaction status

  206.      information plays a similar role.  One obvious testing strategy

  207.      is to call <code class="filename">amcheck</code> functions continuously

  208.      when running the standard regression tests.  See <a class="xref" href="regress-run.html" title="32.1. Running the Tests">Section 32.1</a> for details on running the tests.

  209.     </p></li><li class="listitem"><p>

  210.      File system or storage subsystem faults where checksums happen to

  211.      simply not be enabled.

  212.     </p><p>

  213.      Note that <code class="filename">amcheck</code> examines a page as represented in some

  214.      shared memory buffer at the time of verification if there is only a

  215.      shared buffer hit when accessing the block. Consequently,

  216.      <code class="filename">amcheck</code> does not necessarily examine data read from the

  217.      file system at the time of verification. Note that when checksums are

  218.      enabled, <code class="filename">amcheck</code> may raise an error due to a checksum

  219.      failure when a corrupt block is read into a buffer.

  220.     </p></li><li class="listitem"><p>

  221.      Corruption caused by faulty RAM, or the broader memory subsystem.

  222.     </p><p>

  223.      <span class="productname">PostgreSQL</span> does not protect against correctable

  224.      memory errors and it is assumed you will operate using RAM that

  225.      uses industry standard Error Correcting Codes (ECC) or better

  226.      protection.  However, ECC memory is typically only immune to

  227.      single-bit errors, and should not be assumed to provide

  228.      <span class="emphasis"><em>absolute</em></span> protection against failures that

  229.      result in memory corruption.

  230.     </p><p>

  231.      When <em class="parameter"><code>heapallindexed</code></em> verification is

  232.      performed, there is generally a greatly increased chance of

  233.      detecting single-bit errors, since strict binary equality is

  234.      tested, and the indexed attributes within the heap are tested.

  235.     </p></li></ul></div><p>

  236.   In general, <code class="filename">amcheck</code> can only prove the presence of

  237.   corruption; it cannot prove its absence.

  238.  </p></div><div class="sect2" id="id-1.11.7.11.10"><div class="titlepage"><div><div><h3 class="title">F.2.4. Repairing Corruption</h3></div></div></div><p>

  239.   No error concerning corruption raised by <code class="filename">amcheck</code> should

  240.   ever be a false positive.  <code class="filename">amcheck</code> raises

  241.   errors in the event of conditions that, by definition, should never

  242.   happen, and so careful analysis of <code class="filename">amcheck</code>

  243.   errors is often required.

  244.  </p><p>

  245.   There is no general method of repairing problems that

  246.   <code class="filename">amcheck</code> detects.  An explanation for the root cause of

  247.   an invariant violation should be sought.  <a class="xref" href="pageinspect.html" title="F.22. pageinspect">pageinspect</a> may play a useful role in diagnosing

  248.   corruption that <code class="filename">amcheck</code> detects.  A <code class="command">REINDEX</code>

  249.   may not be effective in repairing corruption.

  250.  </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="adminpack.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="contrib.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="auth-delay.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">F.1. adminpack </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> F.3. auth_delay</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1