Re: GetRelationPath() vs critical sections

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andy Fan <zhihuifan1213@163.com>, pgsql-hackers@postgresql.org, Noah Misch <noah@leadboat.com>, Michael Paquier <michael.paquier@gmail.com>
Date: 2025-02-21T05:20:39Z
Lists: pgsql-hackers

Attachments

On Fri, Feb 21, 2025 at 9:28 AM Andres Freund <andres@anarazel.de> wrote:
> The patch curently uses a hardcoded 6 for the length of MAX_BACKENDS. Does
> anybody have a good idea for how to either
>
> a) derive 6 from MAX_BACKENDS in a way that can be used in a C array size

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.  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...

> b) Use a static assert to check that it fits?

Right, easy stuff like sizeof(CppString2(MAX_BACKENDS)) - 1 can only
work if the token is a decimal number.  I suppose you could just use
constants:

#define MAX_BACKENDS 0x3ffff
#define PROCNUMBER_BITS 18
#define PROCNUMBER_CHARS 6

... and then use the previous magic to statically assert their
relationship inside one translation unit, to keep it out of a widely
included header.

[1] https://lemire.me/blog/2021/06/03/computing-the-number-of-digits-of-an-integer-even-faster/

Commits

  1. Change _mdfd_segpath() to return paths by value

  2. Change relpath() et al to return path by value