Message-ID: <bcc81add-15d6-44f8-88a8-ba9b5b68e0c9@iki.fi>
Date: Wed, 18 Mar 2026 14:18:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Fix uninitialized xl_running_xacts padding
To: Alexander Kuzmenkov <akuzmenkov@tigerdata.com>,
 Michael Paquier <michael@paquier.xyz>
Cc: 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>
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>
 <CALzhyqw_rsQ6akRYhWGZvNXoGn6P_YJEYqSX+aLVHK_SH0czag@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CALzhyqw_rsQ6akRYhWGZvNXoGn6P_YJEYqSX+aLVHK_SH0czag@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/bcc81add-15d6-44f8-88a8-ba9b5b68e0c9%40iki.fi>
Precedence: bulk

On 18/03/2026 12:42, Alexander Kuzmenkov wrote:
> On Wed, Mar 18, 2026 at 7:59 AM Michael Paquier <michael@paquier.xyz 
> <mailto:michael@paquier.xyz>> 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.

I think if you use "BEGIN; INSERT ...; ROLLBACK;" to generate the dead 
tuples instead of DELETE, it will not be sensitive to concurrent 
snapshots like that.

- Heikki