amcheck module provides
functions that allow you to verify the logical consistency of the
structure of relations. If the structure appears to be valid, no
error is raised.
The functions verify various invariants in the structure of the
representation of particular relations. The correctness of the
access method functions behind index scans and other important
operations relies on these invariants always holding. For
example, certain functions verify, among other things, that all
B-Tree pages have items in “logical” order (e.g., for B-Tree indexes on
text, index tuples should be in
collated lexical order). If that particular invariant somehow
fails to hold, we can expect binary searches on the affected page
to incorrectly guide index scans, resulting in wrong answers to
Verification is performed using the same procedures as those used by index scans themselves, which may be user-defined operator class code. For example, B-Tree index verification relies on comparisons made with one or more B-Tree support function 1 routines. See Section 38.15.3 for details of operator class support functions.
amcheck functions may only be
used by superusers.
bt_index_check(index regclass, heapallindexed boolean) returns void
that its target, a B-Tree index, respects a variety of
invariants. Example usage:
test=# SELECT bt_index_check(index => c.oid, heapallindexed => i.indisunique), c.relname, c.relpages FROM pg_index i JOIN pg_opclass op ON i.indclass = op.oid JOIN pg_am am ON op.opcmethod = am.oid JOIN pg_class c ON i.indexrelid = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid WHERE am.amname = 'btree' AND n.nspname = 'pg_catalog' -- Don't check temp tables, which may be from another session: AND c.relpersistence != 't' -- Function may throw an error when this is omitted: AND c.relkind = 'i' AND i.indisready AND i.indisvalid ORDER BY c.relpages DESC LIMIT 10; bt_index_check | relname | relpages ----------------+---------------------------------+---------- | pg_depend_reference_index | 43 | pg_depend_depender_index | 40 | pg_proc_proname_args_nsp_index | 31 | pg_description_o_c_o_index | 21 | pg_attribute_relid_attnam_index | 14 | pg_proc_oid_index | 10 | pg_attribute_relid_attnum_index | 9 | pg_amproc_fam_proc_index | 5 | pg_amop_opr_fam_index | 5 | pg_amop_fam_strat_index | 5 (10 rows)
This example shows a session that performs
verification of the 10 largest catalog indexes in the
database “test”. Verification of the presence
of heap tuples as index tuples is requested for the
subset that are unique indexes. Since no error is raised,
all indexes tested appear to be logically consistent.
Naturally, this query could easily be changed to call
bt_index_check for every
index in the database where verification is
AccessShareLock on the
target index and the heap relation it belongs to. This
lock mode is the same lock mode acquired on relations by
bt_index_check does not
verify invariants that span child/parent relationships,
but will verify the presence of all heap tuples as index
tuples within the index when
true. When a routine,
lightweight test for corruption is required in a live
production environment, using
bt_index_check often provides the best
trade-off between thoroughness of verification and
limiting the impact on application performance and
bt_index_parent_check(index regclass, heapallindexed boolean) returns void
tests that its target, a B-Tree index, respects a variety
of invariants. Optionally, when the
heapallindexed argument is
true, 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
are a superset of the checks that can be performed by
be thought of as a more thorough variant of
bt_index_parent_check also checks
invariants that span parent/child relationships.
follows the general convention of raising an error if it
finds a logical inconsistency or other problem.
ShareLock is required
on the target index by
ShareLock is also acquired on the heap
relation). These locks prevent concurrent data
DELETE commands. The locks also prevent
the underlying relation from being concurrently processed
VACUUM, as well as all
other utility commands. Note that the function holds
locks only while running, not for the entire
additional verification is more likely to detect various
pathological cases. These cases may involve an
incorrectly implemented B-Tree operator class used by the
index that is checked, or, hypothetically, undiscovered
bugs in the underlying B-Tree index access method code.
bt_index_parent_check cannot be used
when Hot Standby mode is enabled (i.e., on read-only
physical replicas), unlike
heapallindexed argument to
verification functions is
additional phase of verification is performed against the table
associated with the target index relation. This consists of a
CREATE INDEX operation, which
checks for the presence of all hypothetical new index tuples
against a temporary, in-memory summarizing structure (this is
built when needed during the basic first phase of
verification). The summarizing structure “fingerprints” every
tuple found within the target index. The high level principle
verification is that a new index that is equivalent to the
existing, target index must only have entries that can be found
in the existing structure.
heapallindexed phase adds
significant overhead: verification will typically take several
times longer. However, there is no change to the relation-level
locks acquired when
heapallindexed verification is
The summarizing structure is bound in size by
maintenance_work_mem. In order to ensure that
there is no more than a 2% probability of failure to detect an
inconsistency for each heap tuple that should be represented in
the index, approximately 2 bytes of memory are needed per
tuple. As less memory is made available per tuple, the
probability of missing an inconsistency slowly increases. This
approach limits the overhead of verification significantly,
while only slightly reducing the probability of detecting a
problem, especially for installations where verification is
treated as a routine maintenance task. Any single absent or
malformed tuple has a new opportunity to be detected with each
new verification attempt.
amcheck can be effective at
detecting various types of failure modes that data page checksums will always fail
to catch. These include:
Structural inconsistencies caused by incorrect operator class implementations.
This includes issues caused by the comparison rules of
operating system collations changing. Comparisons of
datums of a collatable type like
text 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 master server and a standby server is
implicated, possibly because the major 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.
If a problem like this arises, it may not affect each individual index that is ordered using an affected collation, simply because indexed values might happen to have the same absolute ordering regardless of the behavioral inconsistency. See Section 23.1 and Section 23.2 for further details about how PostgreSQL uses operating system locales and collations.
Structural inconsistencies between indexes and the
heap relations that are indexed (when
There is no cross-checking of indexes against their heap relation during normal operation. Symptoms of heap corruption can be subtle.
Corruption caused by hypothetical undiscovered bugs in the underlying PostgreSQL access method code, sort code, or transaction management code.
Automatic verification of the structural integrity of
indexes plays a role in the general testing of new or
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
amcheck functions continuously when
running the standard regression tests. See Section 33.1 for
details on running the tests.
File system or storage subsystem faults where checksums happen to simply not be enabled.
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,
amcheck does not
necessarily examine data read from the file system at the
time of verification. Note that when checksums are
amcheck may raise
an error due to a checksum failure when a corrupt block
is read into a buffer.
Corruption caused by faulty RAM, or the broader memory subsystem.
PostgreSQL does not protect against correctable memory errors and it is assumed you will operate using RAM that uses industry standard Error Correcting Codes (ECC) or better protection. However, ECC memory is typically only immune to single-bit errors, and should not be assumed to provide absolute protection against failures that result in memory corruption.
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.
amcheck can only
prove the presence of corruption; it cannot prove its
No error concerning corruption raised by
amcheck should ever be a false positive.
amcheck raises errors in the
event of conditions that, by definition, should never happen,
and so careful analysis of
amcheck errors is often required.
There is no general method of repairing problems that
amcheck detects. An explanation
for the root cause of an invariant violation should be sought.
pageinspect may play a useful role
in diagnosing corruption that
amcheck detects. A
REINDEX may not be effective in repairing
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.