public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Matthias van de Meent <[email protected]>
Cc: Imran Zaheer <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Konstantin Knizhnik <[email protected]>
Subject: Re: BUG #19519: REPACK can fail due to missing chunk for toast value
Date: Tue, 7 Jul 2026 08:18:55 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEze2WhCRX86ZY2QN7vuGc3wsAyOJbArFSc0i5KtMVnsguA7Kw@mail.gmail.com>
References: <[email protected]>
<CAFC+b6rLNvDzzYxrfLdq7CWbbouHcuOxi-mjEOW1r3qy2uAPMQ@mail.gmail.com>
<CA+UBfan1QukfNDPvb2YpPG-ME4vUduBfbbe5uWptXDryZbtwVA@mail.gmail.com>
<[email protected]>
<CAEze2WhCRX86ZY2QN7vuGc3wsAyOJbArFSc0i5KtMVnsguA7Kw@mail.gmail.com>
On Mon, Jul 06, 2026 at 08:21:41PM +0200, Matthias van de Meent wrote:
> So, in effect, this is an issue that's quite similar to the CIC/RIC
> bug of PG14<14.4, except that
>
> 1.) in this case it's SnapshotAny instead of a
> registered-but-invisible MVCC snapshot;
> 2.) the issue in this case only happens when toast pointers were
> cleaned up and then are dereferenced, rather than HOT chains updated
> and reclaimed since the scan started; and finally
> 3.) this issue dates back a very long time, likely since TOAST, but
> defininitely since PG14 introduced the GlobalVisTestFor apis.
You mean 042b584c7f7d, revert of d9d076222f5b. That rings a bell.
> So I think the only way to fix this is either
> 1.) we update every maintenance process that makes use of SnapshotAny
> and could access TOAST tables to handle errors caused by missing TOAST
> data when the base relation's tuple is RECENTLY_DEAD, and treat those
> as "tuple cleanup has already started, we just weren't aware of it
> yet, so ignore this tuple" (as I mentioned in [1]), or
That seems like an option worth exploring to me, but I doubt that
we'll be able to get something that can be backpatched due to how
invasive it is. I strongly suspect that it would require at least one
table AM change to cope with the fact that we want to let the callers
be OK with TOAST chunks missing in some contexts when grabbing a toast
slice. That's perhaps for the best if we think about potential
regressions, this is scary and old enough that we may still be OK by
living without a backpatch.
> 2.) we set the xmin of the CI/R backend to the current OldestXmin for
> the relation(s) we're currently processing, and so block all cleanup
> of the relevant (toast) data for the duration of this statement or
> whenever we check for a newer xmin for the relation (whilst ignoring
> our current one).
Err, I don't think that would be safe anyway? It's rather uncommon in
practice in schemas, but we could trigger function calls, like index
expressions, domains, whatever, that access data of other tables while
processing one table with a SnapshotAny. The CIC revert of 14.4 was
about such cases.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (21+ 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], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: BUG #19519: REPACK can fail due to missing chunk for toast value
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