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,
