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
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? |