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
-
bufmgr: Fix race in LockBufferForCleanup()
- 74e93d0f0000 19 (unreleased) landed
- 8d85cb889a39 master landed
-
bufmgr: Use atomic sub for unpinning buffers
- 5310fac6e0fc 19 (unreleased) cited
-
bufmgr: Allow some buffer state modifications while holding header lock
- c75ebc657ffc 19 (unreleased) cited