Re: Add “FOR UPDATE NOWAIT” lock details to the log.
От | Fujii Masao |
---|---|
Тема | Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Дата | |
Msg-id | 3926c67e-5242-41d6-b609-2757ae3c84f1@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Add “FOR UPDATE NOWAIT” lock details to the log. (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: Add “FOR UPDATE NOWAIT” lock details to the log.
Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Список | pgsql-hackers |
On 2025/03/11 22:24, Fujii Masao wrote: > > > On 2025/03/11 16:50, Yuki Seino wrote: >>> >>> Instead, wouldn't it be simpler to update LockAcquireExtended() to >>> take a new argument, like logLockFailure, to control whether >>> a lock failure should be logged directly? I’ve adjusted the patch >>> accordingly and attached it. Please let me know what you think! >>> >>> Regards, >> Thank you! >> >> It's very simple and nice. >> It seems like it can also handle other lock failure cases by extending logLockFailure. >> > I agree with this propose. > > Thanks for reviewing the patch! > > I've made some minor cosmetic adjustments. The updated patch is attached. > > Unless there are any objections, I'll proceed with committing it. Pushed the patch. Thanks! 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. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Вложения
В списке pgsql-hackers по дате отправления: