On Mon, Jul 06, 2026 at 05:44:50PM +0200, 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, ...).
Reducing the likelihood of the problem won't address its root. While I looked into all that yesterday, I have looked at an approach based on a more aggressive detoasting for index builds, and it's pretty promising: https://www.postgresql.org/message-id/akyM9G67ZIhPXjmQ%40paquier.xyz The patch includes tests that emulate the report of this thread. The index build path should be able to live with the aggressive detoasting (we need them anyway for the index build). The CLUSTER/VACUUM_FULL/REPACK cases need a deeper chirurgy, as tuple rewrites for the copy_for_cluster() case may not need detoasting at all (case of tuples copied by reference, which is quite a common case when UPDATEs don't touch the external TOAST blobs, just other attributes). At least that's the assumptions the patch relies on. Please note that rather than re-creating a new CF entry, I've attached the other thread to your entry. It would be confusing to have two entries for the same problem. -- Michael
signature.asc
Description: PGP signature
