Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY - Mailing list pgsql-bugs

From Robert Haas
Subject Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Date
Msg-id CA+TgmoYP7BnHXTEoJRUnOuie2J05Qo8ti5mnE2u-1c4Hk+8zJw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
List pgsql-bugs
On Wed, May 25, 2022 at 7:45 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > Basically snapshots don't work anymore. If PROC_IN_SAFE_IC is set,
> > that backend is ignored for the horizon computation for snapshots /
> > on-access HOT pruning. Which means that rows that are visible to the
> > snapshot can be pruned away.
>
> I wondered if we could have different tuple horizons for HOT pruning
> than for vacuum, but looking at ComputeXidHorizons() and users of that,
> it looks complicated to adapt.
>
> Another possibility (than reverting the commit altogether) might be to
> disable HOT pruning while a process is operating on that relation with
> PROC_IN_SAFE_IC.  So CIC/RIC processes are still ignored for VACUUM,
> while not creating corrupted indexes.

I'm not sure that would be a win, because HOT pruning is great as long
as the tuples you're pruning are old enough. Also, it seems like it
would require complex new infrastructure that I think we should be
reluctant to invent in back branches.

It seems to me that we should just revert. As far as I can see, and
for sure I might be missing something, this is a classic case of an
idea that seemed good at the time but turns out not to work. When we
look at a recently HOT-updated tuple, we need to know whether the
original insertion happened before or after the index build. We can't
figure that out if we prune away the tuples that store the xmin values
that we need in order to figure that out. So it turns out we need
everyone to respect that snapshot after all. Bummer.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-bugs by date:

Previous
From: operations i
Date:
Subject: Re: How is this possible "publication does not exist"
Next
From: operations i
Date:
Subject: Re: How is this possible "publication does not exist"