Horton

MAX_BACKENDS size (comment accuracy)

Jacob Brazeal <jacob.brazeal@gmail.com>

View thread View on postgr.es
From: Jacob Brazeal <jacob.brazeal@gmail.com>
To: pgsql-hackers@postgresql.org
Date: 2025-01-25T23:21:17Z
Lists: pgsql-hackers 
Hello all,

In lwlocks.c, we have the following comment, related to LWLock state:


*/* Must be greater than MAX_BACKENDS - which is 2^23-1, so we're fine.
*/#define LW_SHARED_MASK ((uint32) ((1 << 24)-1))*

However, MAX_BACKENDS is set to 2^18-1. Here is the comment in postmaster.h:











*/* * Note: MAX_BACKENDS is limited to 2^18-1 because that's the width
reserved * for buffer references in buf_internals.h.  This limitation could
be lifted * by using a 64bit state; but it's unlikely to be worthwhile as
2^18-1 * backends exceed currently realistic configurations. Even if that
limitation * were removed, we still could not a) exceed 2^23-1 because
inval.c stores * the ProcNumber as a 3-byte signed integer, b) INT_MAX/4
because some places * compute 4*MaxBackends without any overflow check.
This is rechecked in the * relevant GUC check hooks and in
RegisterBackgroundWorker(). */#define MAX_BACKENDS 0x3FFFF*

2^23-1 is noted as an additional upper limit, but I wonder if it'd be
correct to update the comment in lwlocks.c to


*/* Must be greater than MAX_BACKENDS - which is 2^18-1, so we're fine. */*

I'm not sure if this could lead to us actually saving some bits in the
lwlock state, or if we could do anything useful with them anyway.

Jacob

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.