Re: Add “FOR UPDATE NOWAIT” lock details to the log.
Yuki Seino <seinoyu@oss.nttdata.com>
From: Seino Yuki <seinoyu@oss.nttdata.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2024-10-18T00:37:49Z
Lists: pgsql-hackers
Attachments
- v2-0001-add_loginfo_nowait.patch (text/x-diff) patch v2-0001
Currently, we are discussing two improvements: 1. Log output when NOWAIT fails. 2. Adding control via GUC parameters (NOWAIT, lock_timeout, cancellation). > 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. Does this statement mean that for 2, why can NOWAIT but lock_timeout,cancellation cannot? For item 2, the lock_timeout and cancellation will log outputs after the deadlock_timeout(e.g. 1s) has elapsed (by log_lock_waits). At the time this log is output, it is unclear whether the lock will be cancellation or lock_timeout. This means that the timing at "error is determined" and "output logged" do not match. > 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. +1. I will send the version with the GUC parameter added from the previous patch. Regards, -- Yuki Seino NTT DATA CORPORATION
Commits
-
Rename log_lock_failure GUC to log_lock_failures for consistency.
- 73bdcfab35ec 18.0 landed
-
Add GUC option to log lock acquisition failures.
- 6d376c3b0d1e 18.0 landed
-
Split ProcSleep function into JoinWaitQueue and ProcSleep
- 3c0fd64fec8e 18.0 cited