On 2025/02/13 2:31, Jelte Fennema-Nio wrote:
On Wed, 12 Feb 2025 at 12:32, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
What do you think if we simply don't log anything for SKIP LOCKED?
Implementing both NOWAIT and SKIP LOCKED could take time and make the patch
more complex. I'm fine with focusing on the NOWAIT case first as an initial patch.
I think that makes sense. It's a fairly common pattern to use SKIP
LOCKED to implement a concurrent job queue. Having such a usecase
suddenly create lots of logs seems undesirable, especially since it
created no logs at all before. Since NOWAIT already results in an
error (and thus a log), having it add some additional info seems
totally reasonable.
Thank you for the advice. For now, my goal is to output only NOWAIT. Since lock.c cannot reference LockWaitPolicy, I believe we need to extend the IF conditions in LockAcquire, LockAcquireExtended, and their higher-level functions. This could be a pretty significant modification. I’ll think about whether there’s a better approach. I welcome any good ideas from everyone too. As an aside, I also noticed that dontWait(=true) is routed not only from NOWAIT and SKIP LOCKED but also from vacuum and other parts. do_autovacuum(autovacuum.c) -> ConditionalLockDatabaseObject -> LockAcquireExtended Regards,
