| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Michael Banck <mbanck(at)gmx(dot)net> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Set log_lock_waits=on by default |
| Date: | 2024-02-06 16:53:43 |
| Message-ID: | 20240206165343.GA3841415@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I saw this was marked ready-for-committer, so I took a look at the thread.
It looks like there are two ideas:
* Separate log_lock_waits from deadlock_timeout. It looks like this idea
has a decent amount of support, but I didn't see any patch for it so far.
IMHO this is arguably a prerequisite for setting log_lock_waits on by
default, as we could then easily set it higher by default to help address
concerns about introducing too much noise in the logs.
* Set log_lock_waits on by default. The folks on this thread seem to
support this idea, but given the lively discussion for enabling
log_checkpoints by default [0], I'm hesitant to commit something like
this without further community discussion.
[0] https://postgr.es/m/CALj2ACX-rW_OeDcp4gqrFUAkf1f50Fnh138dmkd0JkvCNQRKGA%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-02-06 16:55:57 | Re: Reducing connection overhead in pg_upgrade compat check phase |
| Previous Message | Daniel Gustafsson | 2024-02-06 16:47:56 | Re: Reducing connection overhead in pg_upgrade compat check phase |