Horton

Re: Fix uninitialized xl_running_xacts padding

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
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>
Date: 2026-03-18T12:18:45Z
Lists: 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

Commits

  1. Add test for single-page VACUUM of hash index on INSERT