BUG #19628: Uninterruptible vacuum during hash index processing

The following bug has been logged on the website:

Bug reference: 19628
Logged by: Sergei Kornilov
Email address: sk(at)zsrv(dot)org
PostgreSQL version: 16.14
Operating system: ubuntu
Description:

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=rel(at)entry=0x7f1cf95ec080,
cur_bucket=cur_bucket(at)entry=0,
bucket_buf=bucket_buf(at)entry=11847, bucket_blkno=bucket_blkno(at)entry=1,
bstrategy=0x55f74ae62ca8, maxbucket=32573,
highmask=32767, lowmask=16383, tuples_removed=0x7fff95dc5a98,
num_index_tuples=0x7fff95dc5a90, split_cleanup=false,
callback=0x55f7395a6fa8 <vac_tid_reaped>, callback_state=0x7f1ce9b6d048)
at hash.c:691
691 {
(gdb) n
700 if (split_cleanup)
(gdb) n
717 vacuum_delay_point();
(gdb) p InterruptHoldoffCount
$1 = 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