On 2025/03/11 22:24, Fujii Masao wrote:
>
>
> On 2025/03/11 16:50, Yuki Seino 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!
Using the newly introduced mechanism, we can now easily extend
the log_lock_failure GUC to support additional NOWAIT lock failures,
such as LOCK TABLE ... NOWAIT, ALTER TABLE ... NOWAIT,
ALTER MATERIALIZED VIEW ... NOWAIT, and ALTER INDEX ... NOWAIT.
I've attached a patch implementing this.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
