From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to expose session vs txn lock info in pg_locks view? |
Date: | 2021-01-24 01:12:52 |
Message-ID: | 20210124011252.aixcascbhy6giolc@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-01-24 01:47:47 | Re: Is Recovery actually paused? |
Previous Message | Tomas Vondra | 2021-01-24 00:54:22 | Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits |