Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 8 Jul 2026 09:47:03 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: =?utf-8?B?0KLQtdGB0YLQvtCy0LAg0JXQutCw0YLQtdGA0LjQvdCw?=
 <e.testova@postgrespro.ru>,
	pgsql-hackers@postgresql.org
Subject: Re: VACUUM FULL or CREATE INDEX fails with error: missing chunk
 number 0 for toast value XXX
Message-ID: <ak2eB2XgrvDw3VGN@paquier.xyz>
References: <1779078055.630771314@fmail2.qdit>
 <CAEze2WgRUfoR=tSQQm8zexVNeBbEYi9ZSPztrK63ObyfPxKpBw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="sSknZgIIGtuGsWZT"
Content-Disposition: inline
In-Reply-To: 
 <CAEze2WgRUfoR=tSQQm8zexVNeBbEYi9ZSPztrK63ObyfPxKpBw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ak2eB2XgrvDw3VGN%40paquier.xyz>
Precedence: bulk


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

On Mon, Jul 06, 2026 at 05:44:50PM +0200, 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, ...).

Reducing the likelihood of the problem won't address its root.  While
I looked into all that yesterday, I have looked at an approach based
on a more aggressive detoasting for index builds, and it's pretty
promising:
https://www.postgresql.org/message-id/akyM9G67ZIhPXjmQ%40paquier.xyz

The patch includes tests that emulate the report of this thread.  The
index build path should be able to live with the aggressive detoasting
(we need them anyway for the index build).

The CLUSTER/VACUUM_FULL/REPACK cases need a deeper chirurgy, as tuple
rewrites for the copy_for_cluster() case may not need detoasting at
all (case of tuples copied by reference, which is quite a common case
when UPDATEs don't touch the external TOAST blobs, just other
attributes).  At least that's the assumptions the patch relies on.

Please note that rather than re-creating a new CF entry, I've attached
the other thread to your entry.  It would be confusing to have two
entries for the same problem.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmpNngcACgkQnvQgOdby
QH30ng//cvz9kyIfhuRAfqFZVFCgJ9On1bzWF91ogRmearzLP9MVx5huQbRnI4b4
WxDlJ4XTtqlfkr/WmhIL6gj1zihbHMSNmWRMpIvt/BZjf5GhHG0DPpO7a4/H864A
HS5ZsCiB9eC38Hcd3dVH0oGbYzPC4t6J+beVVWsDH9ecEHAsfqai336a0sqqVctT
qu4H9Ljecs/T7YeYAwCCfQh3W8/IGiuAPoGIRPFqBWIhOX2zN1FFbH4cB1Yi4vmJ
ZoKRBhwuHhmDBZGeMLv9wTK7T76nP1Sr8TZLqDvJ2uoihfJJjfunjlaD7+hC4PwF
lJ7mC9gZLSchL6LZgxU86dpyjfe42PCpMrM5ctDmwVmg5HcCm39pPuQmGkc6ALaY
R0obexieJtpoQHEnd6WK02lkXjf3mJo9T7Xfwv6UxYvQCNxbCaWCmz4XEbxYUe+E
Z6Xloj0QClkrNCSsowr+NrKGI/y2RJig8yB+PSNnO3O5ShJr8QQlTAZgZm8UmJlx
FCX6ijckd7LpGSpFoTttNJCisw10+rTmkJzX17bP+DJP51kSK6yDB9i84AT+pdlc
Pzc9fD+Rh10xJKOC2Ivr8in0dBMjLTHoSY1UKpuZwVMPc4Bf1VmwDFkQGTXPUaFO
r9jisWPaJbXsuZuGU9Jl5bvlQI4Z2yt649dIMRVaNVsB5YineZo=
=G2xr
-----END PGP SIGNATURE-----

--sSknZgIIGtuGsWZT--