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

> On 8 Jul 2026, at 12:43, Тестова Екатерина <e(dot)testova(at)postgrespro(dot)ru> wrote:
>
> Thank you for paying attention to the thread on the same topic. I will
> definitely look at this thread and the proposed patch in the near future.

Hi all,

Thanks for digging into this one. We care about it from an operational
angle, and I'd like to add a reproducer that might make it easier to work on.

> 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.

Yeah, that's why SQLSTATE XX001 (ERRCODE_DATA_CORRUPTED) matters to us. Our
fleet-wide corruption monitoring keys off that error class, so every occurrence
of this race pages me and a team as if it were on-disk corruption. We've
had to add this specific message to an allowlist to stop the noise; our allowlist
currently has just two entries, and I would be very happy to get back to an
empty one.
For completeness, the other entry is
"ERROR: requested WAL segment ... has already been removed"
raised as SQLSTATE 58P01 (undefined_file). I only mention it to
explain why accurate SQLSTATEs matter to us in practice. The TOAST case is
the on-topic one here.

To make iterating on a fix convenient, the attached patch turns the manual
gdb recipe from the first message into a deterministic TAP test. It adds a
"vacuum-before-toast" injection point in vacuum_rel().

The test asserts the correct behavior (CREATE INDEX succeeds), so it fails
on today's codebase.

Best regards, Andrey Borodin.