From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Yuki Seino <seinoyu(at)oss(dot)nttdata(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Date: | 2025-03-23 14:04:29 |
Message-ID: | 797fbca7-e492-4433-adbb-3e70a0101e7e@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-03-23 14:56:28 | Re: Proposal - Allow extensions to set a Plan Identifier |
Previous Message | Alexander Lakhin | 2025-03-23 14:00:00 | Regression test postgres_fdw might fail due to autovacuum |