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

Thank you for Review.

> Could you explain how to reproduce this? In my quick test,
> lock waits canceled by lock_timeout didn’t report either xid or PID,
> so I might be missing something.
It seems to be outputting on my end, how about you?
===== Console =====
postgres=# SHOW log_lock_waits;
  log_lock_waits
----------------
  on
(1 row)

postgres=# SHOW lock_timeout;
  lock_timeout
--------------
  2s
(1 row)

(tx1) postgres=# BEGIN;
       BEGIN
       postgres=*# SELECT aid FROM pgbench_accounts WHERE aid = 1 FOR 
UPDATE;
        aid
       -----
          1
       (1 row)
(tx2) postgres=# SELECT aid FROM pgbench_accounts WHERE aid = 1 FOR 
UPDATE;
       ERROR:  canceling statement due to lock timeout
       CONTEXT:  while locking tuple (0,1) in relation "pgbench_accounts"

===== Log Output =====
# lock start
2024-10-17 17:49:58.157 JST [1443346] LOG:  process 1443346 still 
waiting for ShareLock on transaction 770 after 1000.096 ms
2024-10-17 17:49:58.157 JST [1443346] DETAIL:  Process holding the lock: 
1443241. Wait queue: 1443346.
2024-10-17 17:49:58.157 JST [1443346] CONTEXT:  while locking tuple 
(0,1) in relation "pgbench_accounts"
2024-10-17 17:49:58.157 JST [1443346] STATEMENT:  SELECT * FROM 
pgbench_accounts WHERE aid = 1 FOR UPDATE;
# lock timeout
2024-10-17 17:49:59.157 JST [1443346] ERROR:  canceling statement due to 
lock timeout
2024-10-17 17:49:59.157 JST [1443346] CONTEXT:  while locking tuple 
(0,1) in relation "pgbench_accounts"
2024-10-17 17:49:59.157 JST [1443346] STATEMENT:  SELECT * FROM 
pgbench_accounts WHERE aid = 1 FOR UPDATE;


> I think NOWAIT is often used for lock waits that can fail frequently.
> Logging detailed information for each failed NOWAIT lock wait could
> lead to excessive and potentially noisy log messages for some users.
> 
> On the other hand, I understand that even with NOWAIT, we might want
> to investigate why a lock wait failed. In such cases,
> detailed information about the locking process would be useful.
> 
> Considering both points, I’m leaning toward adding a new GUC parameter
> to control whether detailed logs should be generated for failed
> NOWAIT locks (and possibly for those canceled by lock_timeout).
> Alternatively, if adding a new GUC is not ideal, we could extend
> log_lock_waits to accept a new value like 'error,' which would trigger
> detailed logging when a lock wait fails due to NOWAIT, lock_timeout,
> or cancellation.
That's a good idea. I'll try that.

> I got the following compiler errors;
thank you. I missed it.

Regards,
--
Yuki Seino
NTT DATA CORPORATION