Horton

Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, Петър Славов <pet.slavov@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-05-31T19:34:50Z
Lists: pgsql-bugs 
On 2022-May-31, Peter Geoghegan wrote:

> The assertion failure takes place in heapam_index_build_range_scan(),
> at the point that it is called by amcheck itself -- during an
> opportunistic prune that occurs in passing. This is the specific
> assertion that fails:
> 
> https://github.com/x4m/postgres_g/blob/09d76bdc2528b476ef2f04c793061dcbf23372b5/src/backend/access/heap/pruneheap.c#L762
> 
> Another bug in HEAD definitely seems possible here, but it's hard to
> know without careful testing. The failure that we see is limited to
> the "macOS - Monterey" run, which only fails on this new test.

Actually, it fails on Linux, FreeBSD and macOS -- it's only that one
particular version of the test fails in macOS and the other fails in the
other two systems.  But both of those failures occur in this assertion.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

Commits

  1. Revert changes to CONCURRENTLY that "sped up" Xmin advance

  2. Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.