Re: should we enable log_checkpoints out of the box?
От | Bruce Momjian |
---|---|
Тема | Re: should we enable log_checkpoints out of the box? |
Дата | |
Msg-id | 20211102234646.GB17209@momjian.us обсуждение исходный текст |
Ответ на | Re: should we enable log_checkpoints out of the box? (Michael Banck <michael.banck@credativ.de>) |
Ответы |
Re: should we enable log_checkpoints out of the box?
Re: should we enable log_checkpoints out of the box? |
Список | pgsql-hackers |
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 <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
В списке pgsql-hackers по дате отправления: