Re: VACUUM FULL or CREATE INDEX fails with error: missing chunk number 0 for toast value XXX

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