| From: | Jan Wieck <jan(at)wi3ck(dot)info> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Michael Banck <michael(dot)banck(at)credativ(dot)de>, Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: should we enable log_checkpoints out of the box? |
| Date: | 2021-11-03 03:18:35 |
| Message-ID: | bc31aee3-df2f-563d-c407-f0a1c7a00137@wi3ck.info |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/2/21 20:02, Tom Lane wrote:
> 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.
Making log_checkpoints an enum sort of thing as already suggested might
do that. Or (also already suggested) elevating checkpoint logging once
it happened because of WAL for a while.
The thing I don't want to see us doing is *nothing at all* when pretty
much everyone with some customer experience in the field is saying "this
is the information we want to see post incident and nobody has it so we
sit there waiting for the next time it happens."
Regards
--
Jan Wieck
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2021-11-03 03:41:26 | Re: Skipping logical replication transactions on subscriber side |
| Previous Message | Amit Kapila | 2021-11-03 03:10:26 | Re: pgsql: Document XLOG_INCLUDE_XID a little better |