>>> ing 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.
Yes. It’s still simple for now, but reusing an existing GUC could
complicate future expansions.
I will design a new GUC while ensuring consistency with 'log_lock_waits'.
> 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);
> | ^
> ....
Conflicted with another commit [1]. I'll rebase it later.
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3c0fd64fec8ed6fa3987c33f076fcffbc3f268c3
