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.
Therefore, it is difficult to support lock_timeout and cancellation.
I am thinking of supporting only NOWAIT. What do you think?
Regards,
--
Yuki Seino
NTT DATA CORPORATION
