From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MAX_BACKENDS size (comment accuracy) |
Date: | 2025-02-22 21:39:36 |
Message-ID: | CA+hUKG+nc8=0i1jfQM0wLMXnf4DUses_dxdqpPUVfXamZ3ZdZg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 23, 2025 at 4:16 AM Andres Freund <andres(at)anarazel(dot)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...
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-02-23 00:03:55 | Re: Statistics Import and Export |
Previous Message | Jeff Davis | 2025-02-22 18:39:17 | Re: Statistics Import and Export |