Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 7 Jul 2026 08:18:55 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Imran Zaheer <imran.zhir@gmail.com>,
	Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
	exclusion@gmail.com, pgsql-bugs@lists.postgresql.org,
	Konstantin Knizhnik <knizhnik@garret.ru>
Subject: Re: BUG #19519: REPACK can fail due to missing chunk for toast value
Message-ID: <akw336Xpi9Ck9-Oz@paquier.xyz>
References: <19519-fe02d8ff679d834d@postgresql.org>
 <CAFC+b6rLNvDzzYxrfLdq7CWbbouHcuOxi-mjEOW1r3qy2uAPMQ@mail.gmail.com>
 <CA+UBfan1QukfNDPvb2YpPG-ME4vUduBfbbe5uWptXDryZbtwVA@mail.gmail.com>
 <aktM919ANQGYZcsj@paquier.xyz>
 <CAEze2WhCRX86ZY2QN7vuGc3wsAyOJbArFSc0i5KtMVnsguA7Kw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="j0tAE/LCknK6Cl8z"
Content-Disposition: inline
In-Reply-To: 
 <CAEze2WhCRX86ZY2QN7vuGc3wsAyOJbArFSc0i5KtMVnsguA7Kw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/akw336Xpi9Ck9-Oz%40paquier.xyz>
Precedence: bulk


--j0tAE/LCknK6Cl8z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--j0tAE/LCknK6Cl8z
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmpMN98ACgkQnvQgOdby
QH0NXxAAk1cvcrSYkAnLWW16K3B9MHaG3uQiEPq31c+PxW410xO4897sEkRcDwHq
yMXBFjKtdakBAmmpehuAXFhj1qXisVJuMupMf1WFwe6V3NSXrLl3wMJjeuhmksgC
thHyNbPdK+HscIMpjqBJaK86l19h6tKC1wCs31jVKKgSm3OlKtCuPICVXpviBYE7
o/NTd8JJYugAZ9YiKT9I1s6dUeoeUbHBq4yYX3YmibFLxc8fMzhh+NHy+jYYp76b
aoJDi9C8P81SPc/5PGy4qi06lYfuDvBdELVDWKjaM98a5jk2nPqIxQoQUfoJEoUh
rlKMFK/Ld287GrHp1vmT5qOktyVDb+bpXj8XBREb62ZwDLoK1wFZGf3q2DhNaDQv
1lq/f3J8UEVPBQ4L7xUayEa7XLneSDQwcsSiTTA/qhrxszSoF1bDnK1cIsOH+O32
Qa2T/qiZzoV+YjgWRBNWV3GN7ZFo/UYf633DoIo3X5we6+18B9/VyIRnRW5AfKD9
I+K0ImvMqSyPmjqqPhIPJmUfmwTc11fxwJqoQ/CLAf8xeKUEzfDGL8PKly7IOCH1
KUTWjJ/G54H+BMXPtPq201jyQhJ00Dwze/B7r0dY9nrjtEPv4CRYE7si6ZHU1O2o
t3e2vGsya8gAyVP3HHEThEOpM9QWKXrQ79RkMRSAraMsVA0GHZQ=
=4Uqu
-----END PGP SIGNATURE-----

--j0tAE/LCknK6Cl8z--