Re: BUG #19519: REPACK can fail due to missing chunk for toast value

On Tue, 7 Jul 2026 at 03:42, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Jul 07, 2026 at 01:51:32AM +0200, Matthias van de Meent wrote:
> >
> > Either way, if we can register a snapshot in the REPACK/INDEX backend whose
> > xmin is (*correctly*) registered with the OldestNonRemovableTransactionId()
> > of the relation, then concurrent cleanup won't happen for toast, and we'd
> > also avoid dereferencing those dangling toast pointers. We won't need to
> > actually use that snapshot for any scans; it'll avoid the issue as long as
> > our backend advertises an xmin <= the OldestXmin used in maintenance to
> > hold back pruning/vacuum on the relation.
> >
> > (we can adjust that xmin every once in a while with a newer
> > OldestNonRemovableTransactionId (excl. our own backend) as long as we also
> > adjust the OldestXmin cutoff for the SnapshotAny visibility tests, but I
> > don't suggest to backpatch that even newer system, it'd add significant
> > complications to an already complicated system)
>
> I doubt that anything would be backpatchable, based on how the
> discussion is going. I'm OK to be proven wrong.

I've tried my hand at implementing this, but finally realized it's not
possible to build a safe non-vacuumable AnySnapshot that is certain to
be protected against concurrent cleanup. That needs a guarantee that
the vacuum horizon calculations we're using (and other backends are
going to use) never go backwards, and we can't give that guarantee.
This has to do with the way hot standby feedback is implemented, plus
various other components that allow(ed) xmin to be set from snapshots
which were already dropped from PGPROC's data.

Kind regards,

Matthias van de Meent