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-31T18:54:05Z
Lists: pgsql-bugs 
On 2022-May-31, Peter Geoghegan wrote:

> On Tue, May 31, 2022 at 11:42 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > 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.
> 
> 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.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)

Commits

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

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