Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19628: Uninterruptible vacuum during hash index processing
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: sk@zsrv.org
Reply-To: sk@zsrv.org, pgsql-bugs@lists.postgresql.org
Date: Tue, 18 Aug 2026 12:02:07 +0000
Message-ID: <19628-c2b17d358181a1ea@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19628-c2b17d358181a1ea%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19628
Logged by:          Sergei Kornilov
Email address:      sk@zsrv.org
PostgreSQL version: 16.14
Operating system:   ubuntu
Description:       =20

Hello!

During the installation of minor update (from 16.14 to 16.15), I discovered
that PostgreSQL was shutting down for a long time (about 6 minutes) because
it was waiting for the autovacuum process to terminate.

I was able to find the cause in the vacuum implementation for hash indexes
(this database has a fairly big hash index):

1) vacuum executes hashbulkdelete ( src/backend/access/hash/hash.c )
2) LockBufferForCleanup in loop_top calls HOLD_INTERRUPTS() under the hood
3) then we execute hashbucketcleanup , which can take a long time. Here, the
loop calls vacuum_delay_point (which calls CHECK_FOR_INTERRUPTS), but it
does nothing because HOLD_INTERRUPTS is still in effect.
4) Only at the end of hashbucketcleanup RESUME_INTERRUPTS is called from
LWLockRelease

I checked with gdb: hashbucketcleanup is actually executed with a non-zero
InterruptHoldoffCount.

Breakpoint 1, hashbucketcleanup (rel=3Drel@entry=3D0x7f1cf95ec080,
cur_bucket=3Dcur_bucket@entry=3D0,
    bucket_buf=3Dbucket_buf@entry=3D11847, bucket_blkno=3Dbucket_blkno@entr=
y=3D1,
bstrategy=3D0x55f74ae62ca8, maxbucket=3D32573,
    highmask=3D32767, lowmask=3D16383, tuples_removed=3D0x7fff95dc5a98,
num_index_tuples=3D0x7fff95dc5a90, split_cleanup=3Dfalse,
    callback=3D0x55f7395a6fa8 <vac_tid_reaped>, callback_state=3D0x7f1ce9b6=
d048)
at hash.c:691
691    {
(gdb) n
700        if (split_cleanup)
(gdb) n
717            vacuum_delay_point();
(gdb) p InterruptHoldoffCount
$1 =3D 1

I'm not sure how to properly fix hashbucketcleanup. At the very least, an
additional vacuum_delay_point in hashbulkdelete before LockBufferForCleanup
would improve the situation slightly.

regards, Sergei