Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 18 Mar 2026 15:59:00 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Alexander Kuzmenkov <akuzmenkov@tigerdata.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	Andres Freund <andres@anarazel.de>,
	Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>,
	Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	Thomas Munro <thomas.munro@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Fix uninitialized xl_running_xacts padding
Message-ID: <abpNNPLkGhwIKTxm@paquier.xyz>
References: 
 <CAO6_XqpGYneOe357s4QhOTYpU6UEgk3JJrBiyeuk-9n=f7p=Vw@mail.gmail.com>
 <aoaj45foewpjtu6r5cs67yrx4en3pkurs23e4azv6tbikpw6c3@h3pnaqaksoeg>
 <b607e42e-34ff-414a-b727-dd5ec70babe3@timescale.com>
 <ed73b90b-e153-41ba-a626-2e13da42d6c8@iki.fi>
 <CALzhyqzKTRVsQGj+qDDRVs3Oo0EvffuQvVO0v4rbpWU=SoXKug@mail.gmail.com>
 <CALzhyqzLh9iciLMvT9T-Z+o1ekOPpeP2p2r7tYXNZ8JMSea3Zg@mail.gmail.com>
 <f2875d6b-5ff6-4744-b151-f5ab54cbd2c5@iki.fi>
 <CALzhyqy27==NkjnXYysF1zJj_K2rX5kncJZ9fEdTRVszTjJisg@mail.gmail.com>
 <70674869-2829-4b06-ab93-2f82ea51578c@iki.fi>
 <CALzhyqxrc1ZHYmf5V8NE+yMboqVg7xZrQM7K2c7VS0p1v8z42w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="WRX/hLKtbnAVUHzj"
Content-Disposition: inline
In-Reply-To: 
 <CALzhyqxrc1ZHYmf5V8NE+yMboqVg7xZrQM7K2c7VS0p1v8z42w@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/abpNNPLkGhwIKTxm%40paquier.xyz>
Precedence: bulk


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

On Mon, Mar 16, 2026 at 05:14:10PM +0100, Alexander Kuzmenkov wrote:
> +-- Test insert-driven cleanup of dead index tuples (_hash_vacuum_one_page).
> +TRUNCATE hash_cleanup_heap;
> +INSERT INTO hash_cleanup_heap SELECT 1 FROM generate_series(1, 1000) as i;
> +DELETE FROM hash_cleanup_heap
> +  WHERE ctid IN ('(0,5)','(0,10)','(0,15)','(0,20)','(0,25)',
> +                 '(0,30)','(0,35)','(0,40)','(0,45)','(0,50)');
> +SET enable_seqscan = off;
> +SET enable_bitmapscan = off;
> +SELECT count(*) FROM hash_cleanup_heap WHERE keycol = 1;
> +INSERT INTO hash_cleanup_heap SELECT 1 FROM generate_series(1, 200) as i;
> +RESET enable_seqscan;
> +RESET enable_bitmapscan;
> +
>  -- Clean up.
>  DROP TABLE hash_cleanup_heap;

Hmm.  If I take this SQL sequence independently or with an
installcheck, the one-page VACUUM path is taken during the final
INSERT, but that's not the case of a `make check`.  Could this be made
more stable?  I have not spent a lot of time on it, so I may be
missing something obvious, of course.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmm6TTQACgkQnvQgOdby
QH0HVQ//cCBaElpGgGnt/J6/9pYqoPFQQoFinPDjL3mwo14se6eKkClicfTm2T4y
mePZa+7zdZjuazLknRXVHr7V1FQMKPgFtgVxGNR6UqSulY2ThkHgDsJNAL2sVRBa
EoLpzZXuhzG5pegTz04eHJgJE4lIW+Gb2U2K78RLZ9Ehg/RHeqIR2qOEXwEXgz9N
FvL1H11ABJA/OYQ35C+aE2/dKWFYNA8a9ZDQi02xHwwIGQELR3aX7gglPqXW7BBq
qm5LVXLZfvld2vdzFt2mFCOwK1zSyVuesMU5nj+P5UUOYoUInHtA1+oI0Xw4647g
FFic566tMRtBpCV0VfHuT/3liTXhV4Xx4iH0Xxycd/miQTZ3AXhj0brvEA53OBv7
Wv/nY51ZSF/GUneyThAoZBwBb6fjjAOheHzFb0pDE1Lp5LP6Ydu3IX7VzcHnJMBc
w4bUso6rtzzpvtSh/tZRIYRc5Tv3ufiQq/oICfyO3IExWs/6HFFuACWryyErAcVA
HljUsj7CraUSZfhRJMInGSb/jQ4jJrkIr0JegL7f9DOnjeRzRi00C307JO8ktdOp
CsyDq+FHrCpPd8568dRdNuewKcT+2k0LfA6SxTfwX/OZ3aa4jnBJGKG0qrlbIeR8
+HSwzU22tw7mqzsT/aooX0unbwlPICLEY532WmlDzZK7OuxxpzI=
=YkPW
-----END PGP SIGNATURE-----

--WRX/hLKtbnAVUHzj--