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 <[email protected]> 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. > >
