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

From Michael Paquier
Subject Re: Fix uninitialized xl_running_xacts padding
Date
Msg-id abpNNPLkGhwIKTxm@paquier.xyz
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 Mon, Mar 16, 2026 at 05:14:10PM +0100, Alexander Kuzmenkov wrote:
> +-- Test insert-driven cleanup of dead index tuples (_hash_vacuum_one_page).
> +TRUNCATE hash_cleanup_heap;
> +INSERT INTO hash_cleanup_heap SELECT 1 FROM generate_series(1, 1000) as i;
> +DELETE FROM hash_cleanup_heap
> +  WHERE ctid IN ('(0,5)','(0,10)','(0,15)','(0,20)','(0,25)',
> +                 '(0,30)','(0,35)','(0,40)','(0,45)','(0,50)');
> +SET enable_seqscan = off;
> +SET enable_bitmapscan = off;
> +SELECT count(*) FROM hash_cleanup_heap WHERE keycol = 1;
> +INSERT INTO hash_cleanup_heap SELECT 1 FROM generate_series(1, 200) as i;
> +RESET enable_seqscan;
> +RESET enable_bitmapscan;
> +
>  -- Clean up.
>  DROP TABLE hash_cleanup_heap;

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

Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: vectorized CRC on ARM64
Next
From: Lakshmi N
Date:
Subject: log XLogPrefetch stats at end of recovery