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: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Andrey Borodin <x4mmm@yandex-team.ru>, 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:45:09Z
Lists: pgsql-bugs
On Tue, May 31, 2022 at 12:19 PM Andres Freund <andres@anarazel.de> wrote:
> I don't think that assertion is correct.
>
> Consider transactions aborting concurrently with heap pruning. You could have
> done a HTSV for one chain element, a concurrent abort happened, then you did
> the HTSV for another chain element. If the HTSVs were not in the order of the
> HOT chain you could see HEAPTUPLE_DEAD for an earlier chain element, while
> seeing HEAPTUPLE_INSERT_IN_PROGRESS in a later one.  There's several other
> scenarios with subtransaction aborts as well, I think.

I think that it probably was correct before I rebased the patch on top
of your bugfix commit 18b87b201f. The original version would have
actually called HTSV directly, at the point that it accessed each
tuple from a HOT chain. If nothing else this suggests that the patch
should be clear on this point about not calling HTSV in HOT chain
order.

Offhand I think that it probably would still work if it was limited to
HEAPTUPLE_LIVE (no more asserting in the HEAPTUPLE_INSERT_IN_PROGRESS
case). Not sure if that's worth it. A topic for another time.

-- 
Peter Geoghegan



Commits

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

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