From: | Yuki Seino <seinoyu(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Date: | 2025-02-03 12:30:42 |
Message-ID: | bcaa22a9-191e-411b-89d9-6ec3608ac88d@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
What do you think if we simply don't log anything for SKIP LOCKED?
Regards,
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2025-02-03 12:39:57 | Re: SQLFunctionCache and generic plans |
Previous Message | Sergey Tatarintsev | 2025-02-03 12:23:16 | Re: pgbench with partitioned tables |