Re: Add “FOR UPDATE NOWAIT” lock details to the log.

Yuki Seino <seinoyu@oss.nttdata.com>

From: Yuki Seino <seinoyu@oss.nttdata.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-02-03T12:30:42Z
Lists: pgsql-hackers
Thank you for your comment. Sorry for being late.


> SELECT FOR UPDATE SKIP LOCKED might skip a large number of rows, 
> leading to
> a high volume of log messages from log_lock_failure in your current 
> patch.
> Could this be considered unintended behavior? Would it be better to limit
> the number of log messages per query?
It is necessary to suppress the generation of a large amount of logs due 
to SKIP LOCKED.
But I think that when using SKIP LOCKED, the locks are often 
intentionally bypassed.
It seems unnatural to log only the first write or to set a specific 
number of samples.

What do you think if we simply don't log anything for SKIP LOCKED?


Regards,




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