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
