public inbox for [email protected]
help / color / mirror / Atom feedFrom: Тестова Екатерина <[email protected]>
To: Matthias van de Meent <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: VACUUM FULL or CREATE INDEX fails with error: missing chunk number 0 for toast value XXX
Date: Wed, 08 Jul 2026 10:34:16 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEze2WgRUfoR=tSQQm8zexVNeBbEYi9ZSPztrK63ObyfPxKpBw@mail.gmail.com>
References: <[email protected]>
<CAEze2WgRUfoR=tSQQm8zexVNeBbEYi9ZSPztrK63ObyfPxKpBw@mail.gmail.com>
Matthias, thank you for the review and suggestions.
On Mon, Jul 06, 2026 at 05:44:50PM, 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, ...).
That's a good point. I agree that the bug is not limited to removing toast tuples only during VACUUM.
> We can reduce the likelyhood of this issue by regularly updating the OldestXmin used for HeapTupleSatisfiesVacuum() with > more recent GetOldestNonRemovableTransactionId(heapRelation) in e.g. heapam_index_build_range_scan
At the same time, getting the current OldestXmin more often will definitely not protect (and it won't particularly reduce the likelihood of) against the situation that I have cited. After all, there is an overestimation of definitely_needed in the vacuum interval.
> I suspect the only possible approach here is to be extra careful when detoasting attributes of RECENTLY_DEAD tuples, and > just skip RECENTLY_DEAD tuples if they are missing any parts of their externally toasted attributes.
I've also been thinking about the approach of handling missing TOAST data without stopping the index scan. However, I have concerns about this approach.
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.
I will try to implement patch with careful handling the error of missing data from the visibility race between toast and the main table error in the near future. Based on your experience, can you tell me what I should pay attention to first of all when implementing?
Best regards,
Ekaterina Testova, Postgres Professional
view thread (5+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Re: VACUUM FULL or CREATE INDEX fails with error: missing chunk number 0 for toast value XXX
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox