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

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

  1. Rename log_lock_failure GUC to log_lock_failures for consistency.

  2. Add GUC option to log lock acquisition failures.

  3. Split ProcSleep function into JoinWaitQueue and ProcSleep