Re: Jakub Wartak
> 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).
Ack. Thanks for that field data.
> 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?
The ship "no log spam by default" has definitely sailed since
log_checkpoints defaults to 'on'.
> 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.
Definitely.
Christoph
