On 2024/10/17 22:15, Seino Yuki wrote:
>
>>> Considering both points, I’m leaning toward adding a new GUC parameter
>>> to control whether detailed logs should be generated for failed
>>> NOWAIT locks (and possibly for those canceled by lock_timeout).
>>> Alternatively, if adding a new GUC is not ideal, we could extend
>>> log_lock_waits to accept a new value like 'error,' which would trigger
>>> detailed logging when a lock wait fails due to NOWAIT, lock_timeout,
>>> or cancellation.
>> That's a good idea. I'll try that.
>
> Sorry, I misunderstood.
> The pid and xid are output during deadlock_timeout.
>
>> LOG: process 1443346 still waiting for ShareLock on transaction 770 after 1000.096 ms
>> DETAIL: Process holding the lock: 1443241. Wait queue: 1443346.
> This log output is not triggered by lock_timeout or cancellation.
Yes, these log messages with PID or XID are generated by log_lock_waits, not lock_timeout.
> Therefore, it is difficult to support lock_timeout and cancellation.
>
> I am thinking of supporting only NOWAIT. What do you think?
I'm not sure why it's challenging to provide detailed log messages for lock waits canceled
by lock_timeout or user cancellation, while it's considered feasible for the NOWAIT case.
However, I think it's reasonable to implement this feature step by step. We can start
by adding support for the NOWAIT case and consider extending it to handle lock_timeout and
cancellation scenarios later if possible.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
