Re: GetRelationPath() vs critical sections
От | Thomas Munro |
---|---|
Тема | Re: GetRelationPath() vs critical sections |
Дата | |
Msg-id | CA+hUKG+r4Mj53yjdj=mRg=+NPed_Zq00DD1G71S6xqwg9WySWg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GetRelationPath() vs critical sections (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: GetRelationPath() vs critical sections
Re: GetRelationPath() vs critical sections Re: GetRelationPath() vs critical sections |
Список | pgsql-hackers |
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/
Вложения
В списке pgsql-hackers по дате отправления: