| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Shinya Kato <shinya11(dot)kato(at)gmail(dot)com>, Michael Banck <mbanck(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Set log_lock_waits=on by default |
| Date: | 2025-09-08 07:03:24 |
| Message-ID: | e754e717e962fe341d777f79d2ebc9b45d49dd65.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2025-09-08 at 10:38 +0800, Chao Li wrote:
> I am hesitate to support this change. I agree log_lock_waits is a powerful tool,
> but it’s more like a diagnostic tool. On a high-concurrency system with many tractions
> running at the same time, it may quickly fill up log files and make it difficult
> to find other errors. So, we usually only turn it on when needed, and turn it off
> once debugging is done.
You still can do that - only the default changed.
I think that if your log fills up with messages indicating that sessions are stuck
behind a lock for more than one second, and it is a high concurrency system, you
have got a severe problem that you want to know about.
What I argue is that while log_lock_waits=on is not the correct setting for
everybody, it is the correct setting for the vast majority of databases.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Geier | 2025-09-08 07:11:24 | Re: Use merge-based matching for MCVs in eqjoinsel |
| Previous Message | Zsolt Parragi | 2025-09-08 07:01:24 | Re: OAuth client code doesn't work with Google OAuth |