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-17T13:15:51Z
Lists: pgsql-hackers
>> 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.

Sorry, I misunderstood.
The pid and xid are output during deadlock_timeout.

> LOG:  process 1443346 still waiting for ShareLock on transaction 770 
> after 1000.096 ms
> DETAIL:  Process holding the lock: 1443241. Wait queue: 1443346.
This log output is not triggered by lock_timeout or cancellation.
Therefore, it is difficult to support lock_timeout and cancellation.

I am thinking of supporting only NOWAIT. What do you think?

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