Re: Add “FOR UPDATE NOWAIT” lock details to the log.

Fujii Masao <masao.fujii@oss.nttdata.com>

From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Yuki Seino <seinoyu@oss.nttdata.com>, Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-03-10T18:07:32Z
Lists: pgsql-hackers

Attachments


On 2025/03/10 22:11, Yuki Seino wrote:
>> I encountered a compilation error with the patch. You can also see the error in the patch tester.
>> https://cirrus-ci.com/task/5070779370438656
> 
> Sorry, removed some errors and made some fixes.

Thanks for updating the patch!

You modified heap_lock_tuple() to log lock acquisition failures
using the lock holders and waiters lists returned by LockAcquireExtended().
However, this results in almost identical logging code in both heapam.c and
heapam_handler.c. This approach feels a bit complicated, and if we extend
this feature to other lock failure cases, we'd have to duplicate
the same logging logic elsewhere — which isn't ideal.

Instead, wouldn't it be simpler to update LockAcquireExtended() to
take a new argument, like logLockFailure, to control whether
a lock failure should be logged directly? I’ve adjusted the patch
accordingly and attached it. Please let me know what you think!

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Commits

  1. Rename log_lock_failure GUC to log_lock_failures for consistency.

  2. Add GUC option to log lock acquisition failures.

  3. Split ProcSleep function into JoinWaitQueue and ProcSleep