Hey Thomas, On Mon, Aug 2, 2021 at 6:45 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > Hi Soumyadeep, > > On Sat, Jul 24, 2021 at 5:26 PM Soumyadeep Chakraborty > <soumyadeep2...@gmail.com> wrote: > > On Tue, Jul 20, 2021 at 10:40 PM Thomas Munro <thomas.mu...@gmail.com> > > wrote: > > > I wonder why we need this member anyway, when you can compute it from > > > the address... #define GetPGProcNumber(p) ((p) - ProcGlobal->allProcs) > > > or something like that? Kinda wonder why we don't use > > > GetPGProcByNumber() in more places instead of open-coding access to > > > ProcGlobal->allProcs, too... > > > > I tried this out. See attached v4 of your patch with these changes. > > I like it. I've moved these changes to a separate patch, 0002, for > separate commit. I tweaked a couple of comments (it's not a position > in the "procarray", well it's a position stored in the procarray, but > that's confusing; I also found a stray comment about leader->pgprocno > that is obsoleted by this change). Does anyone have objections to > this?
Awesome, thanks! Looks good. > I was going to commit the earlier change this morning, but then I read [1]. > > New idea. Instead of adding pgprocno to SERIALIZABLEXACT (which we > should really be trying to shrink, not grow), let's look it up by > vxid->backendId. I didn't consider that before, because I was trying > not to get tangled up with BackendIds for various reasons, not least > that that's yet another lock + O(n) search. > > It seems likely that getting from vxid to latch will be less clumsy in > the near future. That refactoring and harmonising of backend > identifiers seems like a great idea to me. Here's a version that > anticipates that, using vxid->backendId to wake a sleeping > SERIALIZABLE READ ONLY DEFERRABLE backend, without having to add a new > member to the struct. > Neat! A Vxid -> PGPROC lookup eventually becomes an O(1) operation with the changes proposed at the ending paragraph of [1]. [1] https://www.postgresql.org/message-id/20210802164124.ufo5buo4apl6yuvs%40alap3.anarazel.de Regards, Soumyadeep (VMware)
