Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Michael Paquier <michael@paquier.xyz>, Петър Славов <pet.slavov@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-05-31T18:42:32Z
Lists: pgsql-bugs
On 2022-May-31, Andrey Borodin wrote: > As seen in CI with reverting only d9d0762: > v3 fails only on MacOS [0,1] > v4 fails on Linux and FreeBSD [2,3] > [0] https://github.com/x4m/postgres_g/runs/6665396918 > [1] https://cirrus-ci.com/task/4580203115577344?logs=test_world#L1571 > [2] https://github.com/x4m/postgres_g/runs/6675153300 > [3] https://cirrus-ci.com/task/6540481319403520?logs=test_world#L842 Hmm ... Exactly what code is being tested here? I see in one of these backtraces that there is a reference to a function called heap_prune_from_root, but I can't find that in the Postgres sources. At this point, I'm clear that d9d076222f5b needs to be reverted because of the interactions with HOT prune, but it's not at all clear to me what is the relationship of the other two commits to bugs. I am going to revert that one now, so that we can continue to diagnose any lingering problem that may be related to the other two commits -- but perhaps it is something else. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
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