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
- x.c (text/x-csrc)
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
-
Change _mdfd_segpath() to return paths by value
- ecbff4378bee 18.0 landed
-
Change relpath() et al to return path by value
- 37c87e63f9e1 18.0 landed