On 2025/02/03 21:30, Yuki Seino wrote:
> Thank you for your comment. Sorry for being late.
>
>
>> SELECT FOR UPDATE SKIP LOCKED might skip a large number of rows, leading to
>> a high volume of log messages from log_lock_failure in your current patch.
>> Could this be considered unintended behavior? Would it be better to limit
>> the number of log messages per query?
> It is necessary to suppress the generation of a large amount of logs due to SKIP LOCKED.
> But I think that when using SKIP LOCKED, the locks are often intentionally bypassed.
> It seems unnatural to log only the first write or to set a specific number of samples.
I don't think so. Some users of SKIP LOCKED may want to understand why locks
were skipped and identify the blockers. Even partial information could still
be valuable to them, I think.
> 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.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
