Horton

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

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

View thread View on postgr.es
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Peter Eisentraut <peter@eisentraut.org>, Yuki Seino <seinoyu@oss.nttdata.com>, Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-05-30T15:28:49Z
Lists: pgsql-hackers 

On 2025/05/30 19:20, Peter Eisentraut wrote:
> On 14.03.25 16:07, Fujii Masao wrote:
>>>>> 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,
>>>> Thank you!
>>>>
>>>> It's very simple and nice.
>>>> It seems like it can also handle other lock failure cases by extending logLockFailure.
>>>> > I agree with this propose.
>>>
>>> Thanks for reviewing the patch!
>>>
>>> I've made some minor cosmetic adjustments. The updated patch is attached.
>>>
>>> Unless there are any objections, I'll proceed with committing it.
>>
>> Pushed the patch. Thanks!
> 
> This patch added a setting "log_lock_failure", but the existing similar setting "log_lock_waits" has a plural.  Is there a reason for this difference?

No, Seino-san and I went with log_lock_failure at the time because
we didn't have a better name suggestion, and we figured we could
revisit the GUC name later if needed. so thanks for bringing it up again!

>  Otherwise, maybe "log_lock_failures" would be better.

Yes, this seems better for consistency with log_lock_waits.

Regards,

-- 
Fujii Masao
NTT DATA Japan 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