Re: Add “FOR UPDATE NOWAIT” lock details to the log.
От | Yuki Seino |
---|---|
Тема | Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Дата | |
Msg-id | af48780d-2d7b-4260-ad81-f6ffeec4358b@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Add “FOR UPDATE NOWAIT” lock details to the log. (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: Add “FOR UPDATE NOWAIT” lock details to the log.
|
Список | pgsql-hackers |
On 2025/02/19 1:08, Fujii Masao wrote: > Just an idea, but how about updating ConditionalXactLockTableWait() to > do the followings? > - Use LockAcquireExtended() instead of LockAcquire() to retrieve the > LOCALLOCK value. > - Generate a log message about the lock holders, from the retrieved > the LOCALLOCK value. > - Return the generated log message to the caller (heap_lock_tuple()), > allowing it to log the message. Thank you for your suggestion. I have two issues to discuss: ### 1. Issue with LockAcquireExtended() It appears that in the dontWait case, LockAcquireExtended() is removing the local lock (locallock). ``` if (locallock->nLocks == 0) RemoveLocalLock(locallock); ``` Instead, the removal of locallock should be handled by ConditionalXactLockTableWait(). ### 2. Issue with the LOCK TABLE Case For the LOCK TABLE scenario, RangeVarGetRelidExtended() calls ConditionalLockRelationOid(), which seems to require a similar modification. ``` # tx1 BEGIN; LOCK TABLE pgbench_accounts; # tx2 BEGIN; LOCK TABLE pgbench_accounts NOWAIT; -- breakpoint -> LockAcquireExtended # parts of CALLSTACK LockAcquireExtended() ConditionalLockRelationOid() RangeVarGetRelidExtended() LockTableCommand() standard_ProcessUtility() ProcessUtility() ``` I don't see a problem with it, though, Do you think these are problems? Regards,
В списке pgsql-hackers по дате отправления: