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.fu...@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.
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
