On Mon, 1 Feb 2021 at 18:42, Craig Ringer <craig.rin...@enterprisedb.com> wrote:
> 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. > Just so this thread isn't left dangling, I'm just not going to get time to follow up on this work with a concrete patch and test suite change. If anyone else later on wants to differentiate between session and txn LWLocks they could start with the approach proposed here.
