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
therea 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
