On Sun, Oct 31, 2021 at 10:24:38PM +0100, Michael Banck wrote: > On Sun, Oct 31, 2021 at 01:16:33PM -0700, Andres Freund wrote: > > 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.
Yes, I agree with this analysis. There is a sense that people who regularly diagnose Postgres problems want this information in the logs by default, while the majority of sites might want silent logs for normal query activity. I realize in this thread that Robert Haas mentioned foreign key violations that would like also appear in logs, but those are ERROR/WARNING etc. messages that can be filtered out with log_min_message. I think if we want to offer a more verbose set of analytic output, by default or not, we might want to relabel them as something other than LOG messages so they can be filtered out with log_min_messages. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
