> On 8 Jul 2026, at 12:43, Тестова Екатерина <[email protected]> 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.
0001-Add-injection-point-test-for-TOAST-heap-vacuum-horiz.patch
Description: Binary data
