Re: toast table corrupted by vacuum - missing chunk number 0 for toast value

Hi Pavel,

On Thu, Aug 20, 2026 at 9:56 PM Pavel Stehule wrote:
> We didn't find any way how this issue can be reproduced. We manually
> executed VACUUM on the database that was restored to the time close
> before this issue - and the data was not broken - but now, I am not
> sure what was the minor version that we used for this test.

I wonder whether the missing TOAST data could be a secondary symptom,
rather than evidence that VACUUM removed TOAST belonging to the current
row version.

I have seen incidents where an old row version became visible again.
Its TOAST data had already been removed legitimately, while the actual
current row version, including its TOAST data, could still be found by
primary key. Reading the resurrected version then failed with the same
missing-chunk error. As far as I recall, in at least one case the old
tuple was considered visible because of its hint bits even though the
transaction status did not agree.

The investigation attached to your original report selects the damaged
tuple directly by ctid. Could you check whether another version of the
same logical row exists, in particular one with the same primary key?
It would be useful to select only ctid, xmin, xmax, and the primary key,
so that inspecting the rows does not itself try to fetch TOAST data. I
would also try it with index and bitmap scans disabled.

The HEAP_UPDATED and HEAP_XMIN_COMMITTED flags on the reported tuple
make this possibility seem worth checking. If another version exists,
the pruning of the TOAST page may have been correct, and the actual
corruption may be that an old heap tuple became visible again. If the
relevant pg_xact data is still available in the restored instance, it
would also be interesting to compare the inserting transaction's status
with the hint bits on this tuple.

Thank you!

Best regards, Andrey Borodin.