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

On 2025/02/13 2:31, Jelte Fennema-Nio wrote:
> On Wed, 12 Feb 2025 at 12:32, Fujii Masao<masao(dot)fujii(at)oss(dot)nttdata(dot)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,