From: | Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | MAX_BACKENDS size (comment accuracy) |
Date: | 2025-01-25 23:21:17 |
Message-ID: | CA+COZaBO_s3LfALq=b+HcBHFSOEGiApVjrRacCe4VP9m7CJsNQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Brazeal | 2025-01-26 00:06:29 | Re: MAX_BACKENDS size (comment accuracy) |
Previous Message | Nathan Bossart | 2025-01-25 22:07:54 | Re: [PATCH] Hex-coding optimizations using SVE on ARM. |