# amcheck

Published articles for amcheck.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## amcheck "table-matches-index" enhancement now available, detects "freeze-the-dead" corruption

DevFeed: [amcheck "table-matches-index" enhancement now available, detects "freeze-the-dead" corruption](<https://devfeed.tech/articles/amcheck-table-matches-index-enhancement-now-available-detects-freeze-the-dead-corruption-33657.md>)

Original publisher: [Read original article](<https://pgeoghegan.blogspot.com/2017/10/amcheck-table-matches-index-enhancement.html>)

Author: Peter Geoghegan (noreply@blogger.com)

Published: 2017-10-26T15:27:00Z

Content type: release

Language: en

Sources: [Peter Geoghegan's blog](<https://devfeed.tech/sources/peter-geoghegan-s-blog.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [releases](<https://devfeed.tech/topics/releases.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [amcheck](<https://devfeed.tech/tags/amcheck.md>), [apt](<https://devfeed.tech/tags/apt.md>), [bugs](<https://devfeed.tech/tags/bugs.md>), [index](<https://devfeed.tech/tags/index.md>), [nbtree](<https://devfeed.tech/tags/nbtree.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [release](<https://devfeed.tech/tags/release.md>), [releases](<https://devfeed.tech/tags/releases.md>)

### AI overview

The article announces the general availability of amcheck v1.2, which adds an optional check that PostgreSQL table tuples have matching index entries. It explains that the enhancement can detect logical corruption, including corruption associated with the "freeze-the-dead" bug, and notes the planned PostgreSQL point-release fixes.

### Source excerpt

I'm pleased to announce that v1.2 of amcheck, a tool for detecting that PostgreSQL relations are logically consistent (that they do not appear to be corrupt) is now generally available. This version adds a big enhancement - the optional ability to check if every tuple that should have an entry in the index does in fact have such an entry. Specifically, we check for a table entry with matching data, as well as a matching heap TID. This happens at the end of the existing tests, as an optional extra step. This enhancement is significant because it seems much more likely to catch corruption in the wild. In general, inconsistencies between a table and its indexes are more likely to occur than inconsistencies between blocks within an index for many reasons. There is simply a much larger window for an inconsistency to arise when something is amiss with database storage that breaks the assumptions PostgreSQL makes during crash recovery, for example. The enhancement is also significant because it played a role in identifying a PostgreSQL data corruption bug that will be fixed in the next point release, scheduled for November 9th, 2017. This bug affects all supported PostgreSQL versions. It was informally dubbed the "freeze-the-dead" bug. November 6 2017 update: The fix was reverted due to additional concerns that came to light. The community is working on a new, more comprehensive fix for the next point release. December 15 2017 update: A new fix has been committed, and will appear in 9.3.21, 9.4.16, 9.5.11, 9.6.7, and 10.2 point releases, scheduled for February 8th, 2018. Packages for v1.2 are available from the community Debian/Ubuntu apt repository, as well as packages from the community Redhat/CentOS/SLES yum repository. Full details on installing these packages are available from the README: https://github.com/petergeoghegan/amcheck/ "Freeze-the-dead" corruption detection I should emphasize that the bug is something that I believe to be very unlikely to hit in the real

## amcheck for Postgres 9.4+ now available from PGDG apt and yum repositories

DevFeed: [amcheck for Postgres 9.4+ now available from PGDG apt and yum repositories](<https://devfeed.tech/articles/amcheck-for-postgres-9-4-now-available-from-pgdg-apt-and-yum-repositories-33656.md>)

Original publisher: [Read original article](<https://pgeoghegan.blogspot.com/2017/10/amcheck-for-postgres-94-now-available.html>)

Author: Peter Geoghegan (noreply@blogger.com)

Published: 2017-10-16T01:44:00Z

Content type: release

Language: en

Sources: [Peter Geoghegan's blog](<https://devfeed.tech/sources/peter-geoghegan-s-blog.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Tool](<https://devfeed.tech/topics/tool.md>)

Tags: [amcheck](<https://devfeed.tech/tags/amcheck.md>), [apt](<https://devfeed.tech/tags/apt.md>), [centos](<https://devfeed.tech/tags/centos.md>), [debian](<https://devfeed.tech/tags/debian.md>), [index](<https://devfeed.tech/tags/index.md>), [internals](<https://devfeed.tech/tags/internals.md>), [nbtree](<https://devfeed.tech/tags/nbtree.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [redhat](<https://devfeed.tech/tags/redhat.md>), [release](<https://devfeed.tech/tags/release.md>), [repositories](<https://devfeed.tech/tags/repositories.md>), [ubuntu](<https://devfeed.tech/tags/ubuntu.md>)

### AI overview

The amcheck tool for detecting PostgreSQL index corruption is now packaged for installation from community Debian/Ubuntu apt repositories and Red Hat/CentOS/SLES yum repositories. These packages support PostgreSQL versions before 10 and install as amcheck_next on PostgreSQL 10. A future enhancement is planned for heap-matches-index verification.

### Source excerpt

amcheck, a tool for index corruption detection, now has packages available from the community Debian/Ubuntu apt repository, as well as packages from the community Redhat/CentOS/SLES yum repository. This means that installations built on those community resources can easily install amcheck, even on PostgreSQL versions before PostgreSQL 10, the release that contrib/amcheck actually first appears in. Full details on installing these packages are available from the README: https://github.com/petergeoghegan/amcheck/ It's also possible to install the packages on PostgreSQL 10, because the extension these packages install is actually named "amcheck_next" (not "amcheck"). Currently, it isn't really useful to install "amcheck_next" on PostgreSQL 10, because its functionality is identical to contrib/amcheck. That's expected to change soon, though. I will add a new enhancement to amcheck_next in the coming weeks, allowing verification functions to perform "heap matches index" verification on top of what is already possible. Many thanks to Christoph Berg and Devrim Gündüz for their help with the packaging.

## amcheck: Verify the logical consistency of PostgreSQL B-Tree indexes

DevFeed: [amcheck: Verify the logical consistency of PostgreSQL B-Tree indexes](<https://devfeed.tech/articles/amcheck-verify-the-logical-consistency-of-postgresql-b-tree-indexes-33654.md>)

Original publisher: [Read original article](<https://pgeoghegan.blogspot.com/2016/05/amcheck-verify-logical-consistency-of.html>)

Author: Peter Geoghegan (noreply@blogger.com)

Published: 2016-05-10T18:50:00Z

Content type: article

Language: en

Sources: [Peter Geoghegan's blog](<https://devfeed.tech/sources/peter-geoghegan-s-blog.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Database](<https://devfeed.tech/topics/database.md>), [bug](<https://devfeed.tech/topics/bug.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [amcheck](<https://devfeed.tech/tags/amcheck.md>), [bug](<https://devfeed.tech/tags/bug.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [database](<https://devfeed.tech/tags/database.md>), [indexes](<https://devfeed.tech/tags/indexes.md>), [internals](<https://devfeed.tech/tags/internals.md>), [locking](<https://devfeed.tech/tags/locking.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [vacuum](<https://devfeed.tech/tags/vacuum.md>), [verify](<https://devfeed.tech/tags/verify.md>)

### AI overview

The article introduces amcheck, a PostgreSQL extension for verifying the logical consistency of B-Tree indexes. It is intended to detect production index corruption with low overhead and generally non-blocking locks, while acknowledging that verification is not fully comprehensive.

### Source excerpt

I've created a project page on Github for amcheck, a tool for verifying the logical consistency of PostgreSQL B-Tree indexes: https://github.com/petergeoghegan/amcheck The tool is primarily useful for detecting index corruption in production database systems. It can do this with low overhead; most verification requires only a non-disruptive lock on the index as it is verified. The strength of the lock taken on an index as it is verified matches that of simple SELECT statements (unless the highest level of verification is requested). The locking involved will generally not block concurrent reads or writes, and will not prevent VACUUM from running concurrently. amcheck is proposed as a contrib extension for PostgreSQL 9.7. This externally maintained version of the extension exists to support earlier versions of PostgreSQL (PostgreSQL 9.4+), and to make the tool available to those that need it sooner. While the level of verification is not totally comprehensive (in particular, there is no verification of indexes against underlying tables), the tool is still likely to detect many subtle problems in practice. amcheck verifies that certain invariants that must hold in the structure of B-Tree indexes actually do, in fact, hold. It's fairly exhaustive. One example of a problem that the tool can detect is inconsistency arising from the recent PostgreSQL 9.5 abbreviated keys glibc issue, where the new-to-9.5 abbreviated keys performance optimization could lead to structurally inconsistent indexes due to a bug in some glibc versions. This issue created a need to get amcheck into the hands of users sooner rather than later. It's not ideal that the tool is maintained externally, since there are complex locking protocols involved; the implementation must make sure that there cannot be false positives to be of much practical use, and so the tool ought to be considered whenever there is a question about these locking protocols. Unfortunately, we ran out of time to get amcheck into