| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| 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 02:38:07 |
| Message-ID: | 80A10B63-DD7E-4057-A4EB-E2CA3CA1A796@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Sep 8, 2025, at 05:46, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> On Thu, 2025-09-04 at 14:12 +0900, Shinya Kato wrote:
>> Due to 635998965 [0], you need to change guc_parameters.dat instead of
>> guc_tables.c.
>
> Thanks for pointing that out to me!
> Here is an updated patch.
>
> Yours,
> Laurenz Albe
> <v2-0001-Default-to-log_lock_waits-on.patch>
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.
But v2 code looks good to me.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2025-09-08 02:39:35 | Re: Should io_method=worker remain the default? |
| Previous Message | Michael Paquier | 2025-09-08 01:27:07 | Re: [PATCH] Update parser README to include parse_jsontable.c |