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

On Tue, 24 May 2022 at 15:02, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Basically:
>
> 1) S1 builds index in phase 2
> 2) S2 inserts tuple t1 (not in the index built in 1), since it's inserted
after that)
> 3) S2 hot updates tuple t1->t2

Not that it matters but is this step even necessary?

> 4) S1 sets PROC_IN_SAFE_IC, builds snapshot, starts validation scan (phase 3)
> 5) S2 hot updates tuple t2->t3

That seems like the key observation. But I wonder if it's even the
only flow where this could be an issue. What happens if t2 is deleted,
can it get pruned away completely?

> 6) Either S1 or S2 performs hot pruning, redirecting t1 to t3, this is only
> possible because PROC_IN_SAFE_IC caused S2's ->xmin to be ignored

Or presumably any other transaction. But ... does the update to t2->t3
not automatically trigger pruning anyways?

> 7) S2 checks t1->t3, finds that t3 is too new for the snapshot, doesn't create
> an index entry

Just to be clear, it would normally have created an index entry (for
the whole HOT chain) because t2 is in the recheck snapshot and
therefore the whole HOT chain wasn't in the initial snapshot. I'm a
little confused here.

> 8) corruption

Aside from amcheck I wonder if we can come up with any way for users
to tell whether their index is affected or at risk. Like, is there a
way to tell from catalog entries if an index was created with CIC?

--
greg