MIME-Version: 1.0
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>
 <abpNNPLkGhwIKTxm@paquier.xyz>
In-Reply-To: <abpNNPLkGhwIKTxm@paquier.xyz>
From: Alexander Kuzmenkov <akuzmenkov@tigerdata.com>
Date: Wed, 18 Mar 2026 11:42:53 +0100
Message-ID: 
 <CALzhyqw_rsQ6akRYhWGZvNXoGn6P_YJEYqSX+aLVHK_SH0czag@mail.gmail.com>
Subject: Re: Fix uninitialized xl_running_xacts padding
To: Michael Paquier <michael@paquier.xyz>
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>
Content-Type: multipart/alternative; boundary="000000000000db847b064d4a1d44"
Archived-At: 
 <https://www.postgresql.org/message-id/CALzhyqw_rsQ6akRYhWGZvNXoGn6P_YJEYqSX%2BaLVHK_SH0czag%40mail.gmail.com>
Precedence: bulk

--000000000000db847b064d4a1d44
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 18, 2026 at 7:59=E2=80=AFAM Michael Paquier <michael@paquier.xy=
z> wrote:

> 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.


I think this might be caused by "make check" running many tests in
parallel, so the deleting transaction is visible to some snapshots, and the
cleanup is not done. Not sure what's the best way to improve this.

--000000000000db847b064d4a1d44
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Mar 18, 2026 at 7:59=E2=80=AFAM Micha=
el Paquier &lt;<a href=3D"mailto:michael@paquier.xyz">michael@paquier.xyz</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hm=
m.=C2=A0 If I take this SQL sequence independently or with an<br>
installcheck, the one-page VACUUM path is taken during the final<br>
INSERT, but that&#39;s not the case of a `make check`.=C2=A0 Could this be =
made<br>
more stable?=C2=A0 I have not spent a lot of time on it, so I may be<br>
missing something obvious, of course.</blockquote><div><br></div><div>I thi=
nk this might be caused by &quot;make check&quot; running many tests in par=
allel, so the deleting transaction is visible to some snapshots, and the cl=
eanup is not done. Not sure what&#39;s the best way to improve this.</div><=
/div></div>

--000000000000db847b064d4a1d44--