Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY

On 2022-May-25, Robert Haas wrote:

> On Wed, May 25, 2022 at 7:45 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> > 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.

Well, the point is that VACUUM could still prune dead tuples that are
newer than the CIC in all *other* tables.  VACUUM cannot run in the
table being processed by CIC/RIC (because of locks), so there's no
change; it's only HOT-pruning in the table being processed that would
change.

> Also, it seems like it would require complex new infrastructure that I
> think we should be reluctant to invent in back branches.

This is definitely true.  And I think this would be expensive, because
we'd have to check in every heap_page_prune call.

> It seems to me that we should just revert.

Deciding to revert makes me sad, because this feature is extremely
valuable for users.  However, I understand the danger and I don't
disagree with the rationale so I can't really object.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"¿Cómo puedes confiar en algo que pagas y que no ves,
y no confiar en algo que te dan y te lo muestran?" (Germán Poo)