On Tue, Jun 30, 2026 at 9:40 AM Fujii Masao <[email protected]> wrote: > > On Sat, Jun 27, 2026 at 10:56 AM Xuneng Zhou <[email protected]> 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.
