On Sat, Feb 22, 2025 at 7:27 AM Andres Freund <andres@anarazel.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? After 024c5211 and 024c5211^, the ID for backends
is a ProcNumber, and that is the thing that must fit in 18 bits. I
like that choice of header too, it's small and limited to definitions
relating to the type and concept of a ProcNumber, which seems like the
right place for this.
Hmm. Why shouldn't the highest usable ProcNumber (that you might call
PROC_NUMBER_MAX, like INT_MAX et all) 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)? 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.
INVALID_PROC_NUMBER is -1, ie it doesn't eat one of the possible
values in the 18-bit space reserved in various tight corners, since 0
is a valid ProcNumber, unless I'm missing something?
+ * 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?
