Re: 048_vacuum_horizon_floor.pl hangs due to wakeup lost inside LockBufferForCleanup

Xuneng Zhou <xunengzhou@gmail.com>

From: Xuneng Zhou <xunengzhou@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-06-30T02:25:48Z
Lists: pgsql-hackers
On Tue, Jun 30, 2026 at 9:40 AM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Sat, Jun 27, 2026 at 10:56 AM Xuneng Zhou <xunengzhou@gmail.com> wrote:
> > > As far as I read the patch, it looks good to me, so I'm inclined to
> > > commit it unless another committer on this thread would like to do so.
> > > But any objections?
> > >
> > > BTW, since the issue was introduced by commits 5310fac6e0f and
> > > c75ebc657ffc, this fix only needs to be applied to master.
> > > Is that correct?
> >
> > I think this is true.
>
> I've pushed the patch. Thanks!

Thanks for pushing!

There seems to be a small nit in the commit message. It says:

"As a result, LockBufferForCleanup() can sleep indefinitely because
the wakeup corresponding to the last conflicting unpin has already been
missed."

Other backends can still pin the buffer and do the final unpin to
unleash the VACUUM process as Andres pointed out upthread. So the
consequence would be more like a no guaranteed wake-up than an
indefinite waiting. However, the possibility of indefinite waiting is
still there as the reported failed test case shows. It seems better to
say like this

"As a result, LockBufferForCleanup() can sleep indefinitely in the
worst case because a future wakeup from unpinner is unguaranteed."


-- 
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.



Commits

  1. bufmgr: Fix race in LockBufferForCleanup()

  2. bufmgr: Use atomic sub for unpinning buffers

  3. bufmgr: Allow some buffer state modifications while holding header lock