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

From Alexander Kuzmenkov
Subject Re: Fix uninitialized xl_running_xacts padding
Date
Msg-id CALzhyqw_rsQ6akRYhWGZvNXoGn6P_YJEYqSX+aLVHK_SH0czag@mail.gmail.com
Whole thread
In response to Re: Fix uninitialized xl_running_xacts padding  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Fix uninitialized xl_running_xacts padding
List pgsql-hackers
On Wed, Mar 18, 2026 at 7:59 AM Michael Paquier <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.

pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Next
From: "Jelte Fennema-Nio"
Date:
Subject: Re: Safer hash table initialization macro