Matthias, thank you for the review and suggestions.
On Mon, Jul 06, 2026 at 05:44:50PM, Matthias van de Meent wrote:
> I think this is insufficient; heap on-access pruning and btree's aggressive
>index tuple removal (when the page would split) will > still cause some
>cleanup of data that could still be considered RECENTLY_DEAD by a possible
>concurrent maintenance > session (CREATE INDEX, REINDEX, VACUUM FULL, ...).
That's a good point. I agree that the bug is not limited to removing toast
tuples only during VACUUM.
> We can reduce the likelyhood of this issue by regularly updating the
>OldestXmin used for HeapTupleSatisfiesVacuum() with > more recent
>GetOldestNonRemovableTransactionId(heapRelation) in e.g.
>heapam_index_build_range_scan
At the same time, getting the current OldestXmin more often will definitely not
protect (and it won't particularly reduce the likelihood of) against the
situation that I have cited. After all, there is an overestimation of
definitely_needed in the vacuum interval.
> I suspect the only possible approach here is to be extra careful when
>detoasting attributes of RECENTLY_DEAD tuples, and > just skip RECENTLY_DEAD
>tuples if they are missing any parts of their externally toasted attributes.
I've also been thinking about the approach of handling missing TOAST data
without stopping the index scan. However, I have concerns about this approach.
The "missing chunk number" error can indicate actual data corruption, not just
a race between heap and TOAST cleanup. We risk masking genuine storage
corruption that should be surfaced to the user.
I will try to implement patch with careful handling the error of missing data
from the visibility race between toast and the main table error in the near
future. Based on your experience, can you tell me what I should pay attention
to first of all when implementing?
Best regards,
Ekaterina Testova, Postgres Professional
