On Sun, 24 Jan 2021 at 09:12, Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2021-01-19 14:16:07 +0800, Craig Ringer wrote: > > AFAICS it'd be necessary to expand PROCLOG to expose this in shmem. > > Probably by adding a small bitfield where bit 0 is set if there's a txn > > level lock and bit 1 is set if there's a session level lock. But I'm not > > convinced that expanding PROCLOCK is justifiable for this. > sizeof(PROCLOCK) > > is 64 on a typical x64 machine. Adding anything to it increases it to 72 > > bytes. > > Indeed - I really don't want to increase the size, it's already a > problem. > > > > It's frustrating to be unable to tell the difference between > session-level > > and txn-level locks in diagnostic output. > > It'd be useful, I agree. > > > > And the deadlock detector has no way to tell the difference when > > selecting a victim for a deadlock abort - it'd probably make sense to > > prefer to send a deadlock abort for txn-only lockers. > > I'm doubtful this is worth going for. > > > > But I'm not sure I see a sensible way to add the info - PROCLOCK is > > already free of any padding, and I wouldn't want to use hacks like > > pointer-tagging. > > I think there's an easy way to squeeze out space: make groupLeader be an > integer index into allProcs instead. That requires only 4 bytes... > > Alternatively, I think it'd be reasonably easy to add the scope as a bit > in LOCKMASK - there's plenty space. > I was wondering about that, but concerned that there would be impacts I did not understand. I'm happy to pursue that angle.
