Re: GetRelationPath() vs critical sections - Mailing list pgsql-hackers

On Sat, Feb 22, 2025 at 5:15 AM Andres Freund <andres@anarazel.de> wrote:
> On 2025-02-21 18:20:39 +1300, Thomas Munro wrote:
> > On Fri, Feb 21, 2025 at 9:28 AM Andres Freund <andres@anarazel.de> wrote:
> > Do we even check the binary digits?  BTW I see a place in lwlock.c
> > that still talks about 2^23-1, looks like it is out of date.
>
> Yea. I actually posted a patch addressing that recently-ish:
> https://postgr.es/m/7bye3hvkdk7ybt4ofigimr4ahshsj657aqatfc5trd5pbp5qd4%40dir2wsx2lgo6
>
> Patch 0001 in that series would be nice to have here, because it moves
> MAX_BACKENDS out of postmaster.h.  I kind had hoped somebody would comment on
> whether pg_config_manual.h is a good place for the define.
>
> I guess we could also move it to storage/procnumber.h.

procnumber.h seems like the right place, at least without a separate
discussion of the ramifications of making it configurable, no?  (I
thought there were ideas about squeezing it down to 16 bits so you
could jam two of 'em into an atomic uint32_t for list headers or
something like that, off-topic here except to say that it seems to
conflict with the idea of making it user-increasable?)

> > Hmmm, I wonder if it would be better to start by declaring how many bits we
> > want to use, given that is our real constraint.  And then:
> >
> > #define PROCNUMBER_BITS 18
> > #define MAX_BACKENDS ((1 << PROCNUMBER_BITS) - 1)
> > #define PROCNUMBER_CHARS DECIMAL_DIGITS_FOR_BITS(PROCNUMBER_BITS)
> >
> > ... with a little helper ported to preprocessor hell from Hacker's
> > Delight magic[1] for that last bit.  See attached.  But if that's a
> > bit too nuts...
>
> This seems a bit too complicated to be worth it. I am inclined to think the
> approach taken in the patch of just having a regression test verifying that
> the numbers match is good enough.
>
> The one arguments I can see for something like DECIMAL_DIGITS_TABLE is that we
> could define OIDCHARS the same way. With a quick grep I couldn't immediately
> find other candidates though.

If anyone ever does consider using something like that, whether to
derive values or just to make assertions that they agree inside a
translation unit somewhere, FTR here's why I posted the simple version
after being temporarily nerdsniped by Hacker's Delight: the
bitswizzling algorithm was translated from branch-free code, which is
fun but irrelevant here and that property didn't even survive the
translation.  So you might as well just use the naive definition of
DECIMAL_DIGITS(n) I posted immediately after.