Re: Fix uninitialized xl_running_xacts padding - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Fix uninitialized xl_running_xacts padding
Date
Msg-id bcc81add-15d6-44f8-88a8-ba9b5b68e0c9@iki.fi
Whole thread Raw
In response to Re: Fix uninitialized xl_running_xacts padding  (Alexander Kuzmenkov <akuzmenkov@tigerdata.com>)
Responses Re: Fix uninitialized xl_running_xacts padding
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Alexander Pyhalov
Date:
Subject: Re: Function scan FDW pushdown
Next
From: Daniel Gustafsson
Date:
Subject: Re: Serverside SNI support in libpq