On 2024/10/18 19:07, Seino Yuki wrote:
>> The choice between adding a new GUC or extending the existing one
>> (e.g., log_lock_waits)
>> is debatable, but I prefer the latter. I'm considering extending log_lock_waits
>> to accept a value like "fail". If set to "on" (the current behavior),
>> detailed logs are generated when the lock wait time exceeds deadlock_timeout.
>> If set to "fail", logs are generated whenever a lock wait fails. If both are
>> specified, logs would be triggered when the wait time exceeds
>> deadlock_timeout or
>> when a lock wait fails.
>
> Thanks for the idea.
> Changed log_lock_waits to an enum type and added fail and all.
> "off" : No log message(default).
> "on" : If over deadlock_timeout(the current behavior).
> "fail" : If lock failed.
> "all" : All pettern.
I'm still thinking about how we should handle logging for lock failures
caused by the nowait option. Extending the existing log_lock_waits parameter
has the advantage of avoiding a new GUC, but it might make configuration
more complicated. I'm starting to think adding a new GUC might be a better option.
Regarding the patch, when I applied it to HEAD, it failed to compile with
the following errors. Could you update the patch to address this?
proc.c:1538:20: error: use of undeclared identifier 'buf'
1538 | initStringInfo(&buf);
| ^
proc.c:1539:20: error: use of undeclared identifier 'lock_waiters_sbuf'
1539 | initStringInfo(&lock_waiters_sbuf);
| ^
proc.c:1540:20: error: use of undeclared identifier 'lock_holders_sbuf'
1540 | initStringInfo(&lock_holders_sbuf);
| ^
....
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
