Re: Set log_lock_waits=on by default

From: Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Set log_lock_waits=on by default
Date: 2023-12-21 14:58:05
Message-ID: CANNMO+LTYrO35eNsa5qbCf+2UuSRWFYFdORGXwyMe=+Sa_MV1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 21, 2023 at 05:29 Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:

> Here is a patch to implement this.
> Being stuck behind a lock for more than a second is almost
> always a problem, so it is reasonable to turn this on by default.

I think it's a very good idea. On all heavily loaded systems I have
observed so far, we always have turned it on. 1s (default deadlock_timeout)
is quite large value for web/mobile apps, meaning that default frequency of
logging is quite low, so any potential suffering from observer effect
doesn't happen -- saturation related active session number happens much,
much earlier, even if you have very slow disk IO for logging.

At the same time, I like the idea by Robert to separate logging of log
waits and deadlock_timeout logic -- the current implementation is a quite
confusing for new users. I also had cases when people wanted to log lock
waits earlier than deadlock detection. And also, most always lock wait
logging lacks the information another the blocking session (its state, and
last query, first of all), but is maybe an off topic worthing another
effort of improvements.

Nik

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2023-12-21 15:00:00 Re: trying again to get incremental backup
Previous Message Bertrand Drouvot 2023-12-21 14:51:24 Re: Track in pg_replication_slots the reason why slots conflict?