Re: A micro-optimisation for ProcSendSignal()

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, ashwinstar(at)gmail(dot)com
Subject: Re: A micro-optimisation for ProcSendSignal()
Date: 2021-12-16 03:00:41
Message-ID: CA+hUKGJo9rEyzvwJ=Jw1LncS4QH4zEyMnLfNqXinAjBrEXQ_JQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 3, 2021 at 2:56 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2021-08-03 13:44:58 +1200, Thomas Munro wrote:
> > In the case of buffer pin waits, we switch to storing the pgprocno of
> > the waiter. In the case of SERIALIZABLE READ ONLY DEFERRABLE waits, we
> > derive the pgprocno from the vxid (though that's not yet as efficient as
> > it could be).
>
> That's kind of an understatement :)

I abandoned the vxid part for now and went back to v3. If/when
BackendId is replaced with or becomes synonymous with pgprocno, we can
make this change and drop the pgprocno member from SERIALIZABLEXACT.

> > + SetLatch(&ProcGlobal->allProcs[pgprocno].procLatch);

> I think some validation of the pgprocno here would be a good idea. I'm worried
> that something could cause e.g. INVALID_PGPROCNO to be passed in, and suddenly
> we're modifying random memory. That could end up being a pretty hard bug to
> catch, because we might not even notice that the right latch isn't set...

Added.

> > /* Accessor for PGPROC given a pgprocno. */
> > #define GetPGProcByNumber(n) (&ProcGlobal->allProcs[(n)])
> > +/* Accessor for pgprocno given a pointer to PGPROC. */
> > +#define GetPGProcNumber(proc) ((proc) - ProcGlobal->allProcs)
>
> I'm not sure this is a good idea. There's no really cheap way for the compiler
> to compute this, because sizeof(PGPROC) isn't a power of two. Given that
> PGPROC is ~880 bytes, I don't see all that much gain in getting rid of
> ->pgprocno.

Yeah, that would need some examination; 0002 patch abandoned for now.

Pushed.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2021-12-16 03:03:11 Re: COPY IN/BOTH vs. extended query mode
Previous Message kuroda.hayato@fujitsu.com 2021-12-16 02:53:44 RE: Allow escape in application_name