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

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,

In response to

Browse pgsql-hackers by date

  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