Hi, On Sun, Oct 31, 2021 at 01:16:33PM -0700, Andres Freund wrote: > On 2021-10-31 15:43:57 -0400, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > > > On 2021-10-31 10:59:19 -0400, Tom Lane wrote: > > >> No DBA would be likely to consider it as anything but log spam. > > > > > I don't agree at all. No postgres instance should be run without > > > log_checkpoints enabled. Performance is poor if checkpoints are > > > triggered by anything but time, and that can only be diagnosed if > > > log_checkpoints is on. > > > > This is complete nonsense. > > Shrug. It's based on many years of doing or being around people doing > postgres support escalation shifts. And it's not like log_checkpoints > incurs meaningful overhead or causes that much log volume.
It could be a bit of reverse-survivorship-bias, i.e., you're only seeing the pathological cases, while 99% of the Postgres installations out there just hum along fine without anybody ever having to look at the checkpoint entries in the log. But yeah, for serious production instances, it makes sense to turn that option on, but I'm not convinced it should be the default. To put another option on the table: maybe a compromise could be to log xlog checkpoints unconditionally, and the (checkpoint_timeout) time ones only if log_checkpoints are set (maybe with some exponential backoff to avoid log spam)? Michael -- Michael Banck Team Lead PostgreSQL Project Manager Tel.: +49 2166 9901-171 Mail: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Management: Dr. Michael Meskes, Geoff Richardson, Peter Lilley Our handling of personal data is subject to: https://www.credativ.de/en/contact/privacy/
