diff options
| author | Peter Geoghegan <pg@bowt.ie> | 2019-03-20 10:41:36 -0700 |
|---|---|---|
| committer | Peter Geoghegan <pg@bowt.ie> | 2019-03-20 10:41:36 -0700 |
| commit | c1afd175b5b2e5c44f6da34988342e00ecdfb518 (patch) | |
| tree | f198d1952a684c67e6580b06fb2c24aa68e0c6d6 /doc/src | |
| parent | fab2502433870d98271ba8751f3794e2ed44140a (diff) | |
| download | postgresql-c1afd175b5b2e5c44f6da34988342e00ecdfb518.tar.gz postgresql-c1afd175b5b2e5c44f6da34988342e00ecdfb518.zip | |
Allow amcheck to re-find tuples using new search.
Teach contrib/amcheck's bt_index_parent_check() function to take
advantage of the uniqueness property of heapkeyspace indexes in support
of a new verification option: non-pivot tuples (non-highkey tuples on
the leaf level) can optionally be re-found using a new search for each,
that starts from the root page. If a tuple cannot be re-found, report
that the index is corrupt.
The new "rootdescend" verification option is exhaustive, and can
therefore make a call to bt_index_parent_check() take a lot longer.
Re-finding tuples during verification is mostly intended as an option
for backend developers, since the corruption scenarios that it alone is
uniquely capable of detecting seem fairly far-fetched.
For example, "rootdescend" verification is much more likely to detect
corruption of the least significant byte of a key from a pivot tuple in
the root page of a B-Tree that already has at least three levels.
Typically, only a few tuples on a cousin leaf page are at risk of
"getting overlooked" by index scans in this scenario. The corrupt key
in the root page is only slightly corrupt: corrupt enough to give wrong
answers to some queries, and yet not corrupt enough to allow the problem
to be detected without verifying agreement between the leaf page and the
root page, skipping at least one internal page level. The existing
bt_index_parent_check() checks never cross more than a single level.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas
Discussion: https://postgr.es/m/CAH2-Wz=yTWnVu+HeHGKb2AGiADL9eprn-cKYAto4MkKOuiGtRQ@mail.gmail.com
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/amcheck.sgml | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/doc/src/sgml/amcheck.sgml b/doc/src/sgml/amcheck.sgml index 8bb60d5c2da..627651d8d4a 100644 --- a/doc/src/sgml/amcheck.sgml +++ b/doc/src/sgml/amcheck.sgml @@ -112,7 +112,7 @@ ORDER BY c.relpages DESC LIMIT 10; <varlistentry> <term> - <function>bt_index_parent_check(index regclass, heapallindexed boolean) returns void</function> + <function>bt_index_parent_check(index regclass, heapallindexed boolean, rootdescend boolean) returns void</function> <indexterm> <primary>bt_index_parent_check</primary> </indexterm> @@ -126,7 +126,10 @@ ORDER BY c.relpages DESC LIMIT 10; argument is <literal>true</literal>, the function verifies the presence of all heap tuples that should be found within the index, and that there are no missing downlinks in the index - structure. The checks that can be performed by + structure. When the optional <parameter>rootdescend</parameter> + argument is <literal>true</literal>, verification re-finds + tuples on the leaf level by performing a new search from the + root page for each tuple. The checks that can be performed by <function>bt_index_parent_check</function> are a superset of the checks that can be performed by <function>bt_index_check</function>. <function>bt_index_parent_check</function> can be thought of as |