Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer

Thank you Yuhang,

That is correct under the (very reasonable) assumption that a backend will
not hold more than one shared lock of the LWLock.

I also studied the current LWLock the implementation and there is room to
make the no-contention path faster. Is that something worth doing,
or is it pointless?

Regards,
Alexandre

On Mon, Aug 24, 2026 at 8:23 AM Yuhang Qiu <iamqyh(at)gmail(dot)com> wrote:

> > Is it undocumented feature, or something that should be fixed?
>
>
> ```C
> #define MAX_BACKENDS_BITS 18
> #define MAX_BACKENDS ((1U << MAX_BACKENDS_BITS)-1)
>
> /* assumes MAX_BACKENDS is a (power of 2) - 1, checked below */
> #define LW_VAL_EXCLUSIVE (MAX_BACKENDS + 1)
> #define LW_VAL_SHARED 1
>
> /* already (power of 2)-1, i.e. suitable for a mask */
> #define LW_SHARED_MASK MAX_BACKENDS
> #define LW_LOCK_MASK (MAX_BACKENDS | LW_VAL_EXCLUSIVE)
> ```
>
> It's documented, not very prominently - see the lwlock.c file header.
> LW_VAL_EXCLUSIVE is MAX_BACKENDS + 1, so overflowing needs MAX_BACKENDS + 1
> shared holders, and InitializeMaxBackends() won't let MaxBackends get that
> big.
>
> So there's nothing to fix here.
>
> Best Regards,
> Yuhang Qiu.
>
>