Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
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:09:04Z
Lists: pgsql-bugs
On Tue, May 31, 2022 at 11:54 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > On 2022-May-31, Peter Geoghegan wrote: > > This includes a patch from me, to make pruning more robust. It could > > technically be a bug in my patch, though a bug revealed by my patch > > seems quite possible too. > > Ah, I see. Well, the explanation that depends on Xmin doesn't apply to > this case. I'm not saying there are no bugs in the other two commits, > just that such bug(s) have a different explanation, so it makes sense to > revert separately. 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. -- Peter Geoghegan
Commits
-
Revert changes to CONCURRENTLY that "sped up" Xmin advance
- e28bb8851969 15.0 landed
- 042b584c7f7d 14.4 landed
-
Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.
- 18b87b201f73 15.0 cited