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.
