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