Re: MAX_BACKENDS size (comment accuracy)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
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-24 11:42:36
Message-ID: 6gs5nstss3fgb5gxd7vl6wszituul7damayktsypolmbx6hzei@2uxvnjnq3xy6
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-02-23 10:39:36 +1300, Thomas Munro wrote:
> 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.

Cool. I now pushed them, including static asserts in inval.c and deadlock.

Thanks for the reviews and the complaint leading to these changes.

> > 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...

Heh, that's odd. I left it like that, didn't seem worth changing given that
it's so far from the real limit...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2025-02-24 11:55:11 Re: Anti join confusion
Previous Message Amit Kapila 2025-02-24 11:31:30 Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary