Horton

Re: MAX_BACKENDS size (comment accuracy)

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Jacob Brazeal <jacob.brazeal@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-02-22T21:39:36Z
Lists: pgsql-hackers 
On Sun, Feb 23, 2025 at 4:16 AM Andres Freund <andres@anarazel.de> wrote:
> We do count the number of lwlock share lockers and the number of buffer
> refcounts within those bits. And obviously 0 lockers/refcounts has to be
> valid. So I think the limit is correct?

Ah, right.  That makes perfect sense.  The 18 bits need to be able to
hold a count, not just an index, and I confused myself about that from
the moment I thought about the name PROC_NUMBER_BITS, which I retract.

> I didn't yet have enough coffe, but isn't the inval.c limit 2^24-1 rather than
> 2^23-1?

Yeah, it has 24 bits of space, but curiously backend_hi is signed, so
(msg->sm.backend_hi << 16) would be sign-extended, so it wouldn't actually
work if you used all 24 bits... which is obviously not a real
problem...

Commits

  1. Fix comment for MAX_BACKENDS.

  2. Add static asserts for MAX_BACKENDS limiting factors

  3. Base LWLock limits directly on MAX_BACKENDS

  4. Move MAX_BACKENDS to procnumber.h

  5. bufmgr: Make it easier to change number of buffer state bits

  6. Remove check hooks for GUCs that contribute to MaxBackends.

  7. Allow Pin/UnpinBuffer to operate in a lockfree manner.