Re: MAX_BACKENDS size (comment accuracy)

Thinking a bit further about this, the purpose of the LW_SHARED_MASK
section of the state is to count the number of lock-sharers. Thus, we only
care about the actual number of backends (up to 2^18-1) here and not the
size of the ProcNumber data type. So I do think the comment should read
2^18-1 and not 2^23-1. Here is a patch to that effect.

On Sat, Jan 25, 2025 at 3:21 PM Jacob Brazeal <jacob.brazeal@gmail.com>
wrote:

> Hello all,
>
> In lwlocks.c, we have the following comment, related to LWLock state:
>
>
> */* Must be greater than MAX_BACKENDS - which is 2^23-1, so we're fine.
> */#define LW_SHARED_MASK ((uint32) ((1 << 24)-1))*
>
> However, MAX_BACKENDS is set to 2^18-1. Here is the comment in
> postmaster.h:
>
>
>
>
>
>
>
>
>
>
>
> */* * Note: MAX_BACKENDS is limited to 2^18-1 because that's the width
> reserved * for buffer references in buf_internals.h.  This limitation could
> be lifted * by using a 64bit state; but it's unlikely to be worthwhile as
> 2^18-1 * backends exceed currently realistic configurations. Even if that
> limitation * were removed, we still could not a) exceed 2^23-1 because
> inval.c stores * the ProcNumber as a 3-byte signed integer, b) INT_MAX/4
> because some places * compute 4*MaxBackends without any overflow check.
> This is rechecked in the * relevant GUC check hooks and in
> RegisterBackgroundWorker(). */#define MAX_BACKENDS 0x3FFFF*
>
> 2^23-1 is noted as an additional upper limit, but I wonder if it'd be
> correct to update the comment in lwlocks.c to
>
>
> */* Must be greater than MAX_BACKENDS - which is 2^18-1, so we're fine. */*
>
> I'm not sure if this could lead to us actually saving some bits in the
> lwlock state, or if we could do anything useful with them anyway.
>
> Jacob
>