From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Subject: | Re: Emit "checkpoint skipped because system is idle" message at LOG level if log_checkpoints is set |
Date: | 2022-01-06 17:26:34 |
Message-ID: | 20220106172634.GY14051@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 05, 2022 at 10:45:06AM +0530, Dilip Kumar wrote:
> +1 to convert to LOG when log_checkpoints is set.
On Thu, Jan 06, 2022 at 04:34:38PM +0900, Kyotaro Horiguchi wrote:
> Agreed. -1 to just raising elevel of the message.
On Thu, Jan 06, 2022 at 06:58:14PM +0800, Julien Rouhaud wrote:
> -1 too.
>
> > If someone keen to show some debug messages, it is viable for
> > arbitrary messages by lowering log_min_messages then inserting a
> > custom filter to emit_log_hook. It invites some overhead on
> > irrelevant processes, but that overhead would be avoidable with a
> > *bit* dirty hack in the filter,
> >
> > We might want to discuss more convenient or cleaner way to get the
> > same result.
>
> We could add a checkpoint_skipped counter to pg_stat_bgwriter for instance.
+1 (cc Melanie)
Bharath: there's no agreement that this behavior change is desirable, so I
suggest to close the CF entry.
Actually, I suggest to not immediately create CF entries; instead, wait to see
if there's any objections or discussion. FWIW, I try to wait a day before
creating a CF entry, since the scope/goal/desirability of a thread can change
dramatically. This avoids burdening reviewers with the task of later
discussing whether it's okay to close a CF entry.
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2022-01-06 18:02:19 | Re: Suggestion: optionally return default value instead of error on failed cast |
Previous Message | Andrew Dunstan | 2022-01-06 17:18:26 | Re: Suggestion: optionally return default value instead of error on failed cast |