On Fri, Jul 19, 2024 at 5:13 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Jul 19, 2024 at 10:22 AM Christoph Berg <myon@debian.org> wrote:
[..]
> > Let's fix the default. People who have a problem can still disable it,
> > but then everyone else gets the useful messages in the first iteration.
>
> Reasonable.
>
I have feeling that we have three disconnected class of uses:
1. dev/testing DBs: where frankly speaking nobody cares about such DBs
until they stop/crash; this also includes DBs from new users on dev
laptops too
2. production systems: where it matters to have log_lock_waits=on (and
people may start getting nervous if they don't have it when the issue
strikes)
3. PG on embedded hardware, where it would be worth to be actually
disabled and not consume scare resources
I would like to +1 too to the default value of log_lock_waits=on due
to mostly working nearby use case #2, and because due to my surprise,
we had __ 74.7% __ of individual installations having it already as
'on' already within last year support reports here at EDB (that may be
biased just to class of systems #2).
But I could be easily convinced too, that it is the embedded space
(#3) that has the biggest amount of default installations, so we
should stick log_lock_waits=off by default. However, I believe that
such specialized use of PG already might require some "customizations"
first to even further reduce e.g shared_buffers, right?
I would also like to believe that if people try to use PostgreSQL for
the first time (use case #1), they would be much better served when
the log would contain info about stuck sessions.
Also, if there's ever any change to the default, it should be put into
Release Notes at front to simply warn people (especially those from
embedded space?).
-J.
