On 2025/02/18 18:33, Yuki Seino wrote:
>
> 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
believewe need to extend the IF conditions in LockAcquire, LockAcquireExtended, and their higher-level functions. This
couldbe a pretty significant modification. I’ll think about whether there’s a better approach. I welcome any good ideas
fromeveryone too.
Just an idea, but how about updating ConditionalXactLockTableWait() to do the followings?
- Use LockAcquireExtended() instead of LockAcquire() to retrieve the LOCALLOCK value.
- Generate a log message about the lock holders, from the retrieved the LOCALLOCK value.
- Return the generated log message to the caller (heap_lock_tuple()), allowing it to log the message.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
