Re: MAX_BACKENDS size (comment accuracy)

Hi,

On 2025-02-22 18:54:08 +1300, Thomas Munro wrote:
> On Sat, Feb 22, 2025 at 7:27 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> +#define MAX_BACKENDS_BITS 18
> +#define MAX_BACKENDS ((1 << MAX_BACKENDS_BITS)-1)
>
> +1 for working forwards from the bits. But why not call it
> PROC_NUMBER_BITS?

Partially just because it was named MAX_BACKENDS historically. But also
because it seems like it could be misleading - ProcNumber has more bits than
PROC_NUMBER_BITS would indicate.

> Hmm. Why shouldn't the highest usable ProcNumber (that you might call
> PROC_NUMBER_MAX, like INT_MAX et all)

FWIW, I don't think we should name it _MAX, precisely because of INT_MAX
etc. INT_MAX indicate the actual range of the type, which isn't what we're
dealing with here.

> be (1 << PROC_NUMBER_BITS) - 1, and wouldn't that imply that MAX_BACKENDS
> should actually be 1 << PROC_NUMBER_BITS and that any valid ProcNumber (a
> 0-based index) should be *less than* MAX_BACKENDS (a count)?

I don't *think* so, but I'm good at off-by-one-ing:

> In other words, doesn't the current coding arbitrarily prevent the use of
> one more backend, the one that has the highest ProcNumber representable in
> 18 bits? If I'm right about that I think it is perhaps related to the use
> of 0 as an invalid/unset BackendId before the ProcNumber-only redesign.

We do count the number of lwlock share lockers and the number of buffer
refcounts within those bits. And obviously 0 lockers/refcounts has to be
valid. So I think the limit is correct?

> + * 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
>
> Should those two constraints have their own assertions?

Probably wouldn't hurt, even though I think it's unlikely to matter anytime
soon.

I didn't yet have enough coffe, but isn't the inval.c limit 2^24-1 rather than
2^23-1?

Greetings,

Andres Freund