Hi,
On 2023-11-28 20:52:31 +0800, Jingxian Li wrote:
> postgres=*# lock table test in exclusive mode ;
>
>
> T4
>
> Case 1:
>
> postgres=*# lock table test in share row exclusive mode nowait;
>
> ERROR: could not obtain lock on relation
"test"
>
> --------------------------------------------
>
> Case 2:
>
> postgres=*# lock table test in share row exclusive mode;
>
> LOCK TABLE
>
>
>
>
> At T4 moment in session A, (case 1) when executing SQL “lock table test in share row exclusive mode nowait;”, an
erroroccurs with message “could not obtain lock on relation test";However, (case 2) when executing the SQL above
withoutnowait, lock can be obtained successfully.
>
> Digging into the source code, I find that in case 2 the lock was obtained in
> the function ProcSleep instead of LockAcquireExtended. Due to nowait logic
> processed before WaitOnLock->ProcSleep, acquiring lock failed in case
> 1. Can any changes be made so that the act of such lock granted occurs
> before WaitOnLock?
I don't think that'd make sense - lock reordering is done to prevent deadlocks
and is quite expensive. Why should NOWAIT incur that cost?
>
>
> Providing a more universal case:
>
> Transaction A already holds an n-mode lock on table test. If then transaction A requests an m-mode lock on table
Test,m and n have the following constraints:
>
> (lockMethodTable->conflictTab[n] & lockMethodTable->conflictTab[m]) == lockMethodTable->conflictTab[m]
>
> Obviously, in this case, m<=n.
>
> Should the m-mode lock be granted before WaitOnLock?
>
>
>
> In the case of m=n (i.e. we already hold the lock), the m-mode lock is
> immediately granted in the LocalLock path, without the need of lock conflict
> check.
Sure - it'd not help anybody to wait for a lock we already hold - in fact it'd
create a lot of deadlocks.
> Based on the facts above, can we obtain a weaker lock (m<n) on the same
> object within the same transaction without doing lock conflict check?
Perhaps. There's no inherent "lock strength" ordering for all locks though.
Greetings,
Andres Freund