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.
