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
-
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