MAX_BACKENDS size (comment accuracy) - Mailing list pgsql-hackers

From Jacob Brazeal
Subject MAX_BACKENDS size (comment accuracy)
Date
Msg-id CA+COZaBO_s3LfALq=b+HcBHFSOEGiApVjrRacCe4VP9m7CJsNQ@mail.gmail.com
Whole thread Raw
List 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

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: [PATCH] Hex-coding optimizations using SVE on ARM.
Next
From: Jacob Brazeal
Date:
Subject: Re: MAX_BACKENDS size (comment accuracy)