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-10 18:07:32 |
Message-ID: | 58ba2d49-3893-4f38-92d2-15403f8463b7@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025/03/10 22:11, Yuki Seino wrote:
>> I encountered a compilation error with the patch. You can also see the error in the patch tester.
>> https://cirrus-ci.com/task/5070779370438656
>
> Sorry, removed some errors and made some fixes.
Thanks for updating the patch!
You modified heap_lock_tuple() to log lock acquisition failures
using the lock holders and waiters lists returned by LockAcquireExtended().
However, this results in almost identical logging code in both heapam.c and
heapam_handler.c. This approach feels a bit complicated, and if we extend
this feature to other lock failure cases, we'd have to duplicate
the same logging logic elsewhere — which isn't ideal.
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,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachment | Content-Type | Size |
---|---|---|
v9-0001-Add-GUC-option-to-log-lock-acquisition-failures.patch | text/plain | 22.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-03-10 18:23:12 | Re: AIO v2.5 |
Previous Message | Álvaro Herrera | 2025-03-10 17:58:44 | Re: bogus error message for ALTER TABLE ALTER CONSTRAINT |