Bruce Momjian <bruce@momjian.us> writes:
> On Sun, Oct 31, 2021 at 10:24:38PM +0100, Michael Banck wrote:
>> 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'm still of the position that the default ought to be that a
normally-functioning server generates no ongoing log output.
Only people who have got Nagios watching their logs, or some
such setup, are going to want anything different. And that is
a minority use-case. There are going to be way more people
bitching because their postmaster log overflowed their disk
than there will be people who are happier because you made
such output the default. (Don't forget that our default
logging setup does not rotate the logs.)
However, I'm prepared to accept a tight definition of what
"normally-functioning" means. For instance, I don't have a
problem with the idea of having log_autovacuum_min_duration
defaulting to something positive, as long as it's fairly large.
Then it's only going to emit anything if there is a situation
that really needs attention.
My objection to log_checkpoints=on is that that's going to produce
a constant stream of messages even when *nothing at all* is wrong.
Worse yet, a novice DBA would likely have a hard time understanding
from those messages whether there was anything to worry about or not.
If we could design a variant of log_checkpoints that would produce
output only when the situation really needs attention, I'd be fine
with enabling that by default.
regards, tom lane
