Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 8 Jul 2026 10:10:11 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Imran Zaheer <imran.zhir@gmail.com>,
	Alexander Lakhin <exclusion@gmail.com>,
	PostgreSQL mailing lists <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: <ak2jc7mIhcMDkm-k@paquier.xyz>
References: 
 <CAFC+b6rLNvDzzYxrfLdq7CWbbouHcuOxi-mjEOW1r3qy2uAPMQ@mail.gmail.com>
 <CA+UBfan1QukfNDPvb2YpPG-ME4vUduBfbbe5uWptXDryZbtwVA@mail.gmail.com>
 <aktM919ANQGYZcsj@paquier.xyz>
 <CAEze2WhCRX86ZY2QN7vuGc3wsAyOJbArFSc0i5KtMVnsguA7Kw@mail.gmail.com>
 <akw336Xpi9Ck9-Oz@paquier.xyz>
 <CAEze2WgBjhf6KTKuJ-UqHHGj9Z66f62grmJgZ1EazvMH9HU+XA@mail.gmail.com>
 <akxZiYmGhvNfPVvh@paquier.xyz>
 <akyM9G67ZIhPXjmQ@paquier.xyz>
 <CAFC+b6rOdx6rMi_numCrK8cM4z_HWQKrAcBY0dfrRcRWTRpsBQ@mail.gmail.com>
 <ak16dMkUP1pS0rCn@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="ejyeCqjFabTtqsVV"
Content-Disposition: inline
In-Reply-To: <ak16dMkUP1pS0rCn@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/ak2jc7mIhcMDkm-k%40paquier.xyz>
Precedence: bulk


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

On Wed, Jul 08, 2026 at 07:15:16AM +0900, Michael Paquier wrote:
> One thing that I still don't like much in the patch as written is my
> use of a missing_ok argument, which feels super confusing as it
> applies only to the underlying external TOAST, if the relation has
> any.  I'd be tempted to rewrite this portion of the patch with a
> uint32 flags.  Even if we assign one value for now (say MISSING_TOAST,
> MISSING_TOAST_OK or whatever), it would allow more flexibility on ABI
> grounds if we want more like states in the future across this portion
> of the stack.  Again, I strongly doubt that we will be able to
> backpatch any of that.

A couple of extra notes while I do not forget about that stuff..  The
patch may be better split into two if we go with this approach, as the
index build and rewrite paths require different solutions:
- One for the rewrite path.  It makes little sense to do any kind of
aggressive early detoasting because it may be wasteful due to the
tuple rewrites that update their data with only copies by reference
(main relation tuple is rewritten, reuses the same external TOAST
tuple).  For workloads where UPDATEs do not touch the TOASTed
attributes, that would be a waste.
- One for the index build path, which is actually too aggressive with
its early detoasting, now that I think about it.  There should be no
need to perform a detoast for anything else than the attributes that
are used in the index definition or the attributes that are used in
index expressions.  So as written this patch would lead to a
regression.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmpNo3MACgkQnvQgOdby
QH2WRw/9FJ/ouKXPw0Djajy+YLKvWUmswSa2E1AznuLTvOw5iTtdKUXJd5Lr5Q/T
YFyaQMMJy6IVcbxoEgUolBTbCUqM39qIhRwb+x0cA4tGNBeFq/Qv5lBW6oCrE4h0
S7Wos1tKc6G7Ub1vHTIh326gAr7yZVN/tVL4zT1ih7oVoUbyqrKLcxP/UYLIoBY8
8W4VT6wbOysptahbf5XTWaxDMAZ68zfXii5hgBRyEaKu7MkSPQNO6EF/FBePaeRM
i5vC6JwdnDi8dF7UWxO8m5X0+LnIPXunhBqEx1jNl0fO8XeJyHa16LmkBXYfU6M0
EMEkEPPMa5fX9WZi1xD3bWCkW4nNKuYov9PGmAgfgXo9ges0pdonD9WOLs5RTPbD
6ToMIOBGtkR4GDY7Qsq5AQMPPFDnqOqzLxsZk5iSBIE5hN7tt65dMwJRBKWliTut
Zw/3L+uA2hNme4BEbPd/bh3rUov+Rkf2pl2Axx6LQ70taypooHIxPtBe2TMybQ67
OWAZP2JyaFosgrgb/G+WaNwqkIU/RGRVm+VwiK95Qpkxhg3IPUsUnnIrrq0kDuHm
0P1xAt9hdGOURQLJhYbHvtHszWJhwpo3CBgasgxxG5HJSutCxQuXMx6TIHDzC27p
3txh/Wnxvl3PslZSLx1NOwMLKU6F4SV7QJHXvhEq2T1u3J9uttM=
=wFBB
-----END PGP SIGNATURE-----

--ejyeCqjFabTtqsVV--