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

On Tue, Jul 07, 2026 at 10:42:33AM +0900, Michael Paquier wrote:
> I've quickly thought about some try/catch blocks while detoasting, but
> I cannot really get how this would be entirely bullet-proof. It seems
> to me that we'll live better if we bite the bullet and go for the
> invasive change of passing a state across the stack to let detoasting
> know that we are dealing with a rewrite.

I have been playing with this idea, with two approaches. For the
REPACK and VACUUM cases, things looked pretty straight for both
approaches, but the index build got hairy in the first case:
1) Attempt to shortcut missing TOAST chunks when doing index builds.
For hash and btree, things get straight with index_form_tuple(). But
I've quickly faced a wall with GIN (extractValue support function) and
GiST (compress function). So at the end I gave up on that, as it
would require more facilities than this looks worth for.
2) A more aggressive pre-detoast when building a range of values for
tuples that we are seeing as already dead, which should be able to
work across all index AMs transparently when we are dealing with dead
tuples (that should be kept in a per-tuple context). That's what I
guess you've mentioned upthread.

Option 2 leads to a much nicer result overall, with the attached
passing my regression tests and Alexander's case as well (highly
concurrent thing sent yesterday). The rest of the patch is kind of
boring, where I have been trying to get a missing_ok state across the
stack to let the toast slice fetch bypass the case of missing chunks
when we are OK with it due to the rewrites. That still feels crude,
but the simplicity is appealing here, as much as the rather low
invasiveness.

Thoughts or comments?
--
Michael