Horton

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

Jelte Fennema-Nio <postgres@jeltef.nl>

View thread View on postgr.es
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Yuki Seino <seinoyu@oss.nttdata.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-02-12T17:31:53Z
Lists: pgsql-hackers 
On Wed, 12 Feb 2025 at 12:32, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> > What do you think if we simply don't log anything for SKIP LOCKED?
>
> Implementing both NOWAIT and SKIP LOCKED could take time and make the patch
> more complex. I'm fine with focusing on the NOWAIT case first as an initial patch.

I think that makes sense. It's a fairly common pattern to use SKIP
LOCKED to implement a concurrent job queue. Having such a usecase
suddenly create lots of logs seems undesirable, especially since it
created no logs at all before. Since NOWAIT already results in an
error (and thus a log), having it add some additional info seems
totally reasonable.

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