Hi,
Thank you for looking into this all!
On Tue, 22 Sept 2026 at 03:12, shihao zhong <zhong950419@gmail.com> wrote:
>
> Right, the per IO check puts the spinlock in the hot path.
>
> The barrier also only releases, it does not destroy, so it does not
> fix what Nazir reported. The hash table in the IO worker keeps
> growing either way. Nothing pins those entries in an IO worker, and
> smgrdestroyall only zaps unpinned ones, so destroying them there
> should be safe.
Correct.
> That suggests a version with no lock at all. Keep the cleanup where
> Nazir put it, at a safe point in the worker loop, but trigger it on a
> local condition, the number of unpinned entries being over a cap,
> rather than on a checkpoint generation. No shared state, and it also
> covers a worker that never goes idle.
We need to make a function call to hash_get_num_entries() for each IO
to check number of unpinned entries, which doesn't sound good to me.
This is especially true for the partitioned case.
For now, I used the number of IOs (capped at 1024) since the last smgr
cleanup. This solution removes CheckpointerShmem->ckpt_lck contention
and worker goes idle problem.
--
Regards,
Nazir Bilal Yavuz
Microsoft
