On Sun, Oct 31, 2021 at 10:59:19AM -0400, Tom Lane wrote: > Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> writes: > > How about we enable it out of the box? > > No. > > The general policy at the moment is that a normally-functioning server > should emit *no* log traffic by default (other than a few messages > at startup and shutdown). log_checkpoints is a particularly poor > candidate for an exception to that policy, because it would produce so > much traffic. No DBA would be likely to consider it as anything but > log spam.
Huh? As I see it, this is something that everyone should look at, at least sometimes, and may be particularly important when deploying a new instance. In order to set shared_buffers/checkpoint_timeout/wal_size, it's important to know what fraction of the buffers were dirty during a typical/peak checkpoint. And important to know if fsync is taking unreasonably large amount of time. In cases that log_checkpoints writes "so much", then checkpoint_warning would also be complaining, already. I think writing a low volume of "routine" messages would allow some confidence that a server is functioning normally. If there's nothing being logged at all, maybe logging isn't working, maybe I'm looking in the wrong place, or maybe the server hasn't completed a checkpoint in the last 3 weeks and we're in deep trouble - the absence of any logs at all does not support high confidence in the health of one's cluster. Note my somewhat recent message at https://www.postgresql.org/message-id/20210615161830.gq31...@telsasoft.com: On Tue, Jun 15, 2021 at 11:18:30AM -0500, Justin Pryzby wrote: > I propose to change some defaults: > > log_autovacuum_min_duration = 0 > log_checkpoints = on > log_lock_waits = on (and log_recovery_conflict_waits too?) > log_temp_files = 128kB Robert opined that autovacuum shouldn't be zero, but shouldn't be disabled either, which is fine. Any value that doesn't completely disable logging these events would be preferable - same for log_temp_files.
