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

Fujii Masao <masao.fujii@oss.nttdata.com>

From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Yuki Seino <seinoyu@oss.nttdata.com>, Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-03-23T14:04:29Z
Lists: pgsql-hackers

On 2025/03/21 15:21, Yuki Seino wrote:
>> Pushed the patch. Thanks!
> 
> Thank you. I'm very happy !!
> 
> 
>> Using the newly introduced mechanism, we can now easily extend
>> the log_lock_failure GUC to support additional NOWAIT lock failures,
>> such as LOCK TABLE ... NOWAIT, ALTER TABLE ... NOWAIT,
>> ALTER MATERIALIZED VIEW ... NOWAIT, and ALTER INDEX ... NOWAIT.
>>
>> I've attached a patch implementing this.
> That's a very good suggestion.
> 
> There is just one thing that bothers me.
> ConditionalLockRelationOid() seems to be used by autovacuum as well.
> Wouldn't this information be noise to the user?

Yes, logging every autovacuum lock failure would be too noisy.
I was thinking that log_lock_failure should apply only to LOCK TABLE ... NOWAIT,
but per the current code, restricting it that way seems difficult.

Anyway, expanding log_lock_failure further requires more discussion and design work,
which isn't feasible within this CommitFest. So, I'm withdrawing the patch for now.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
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