Re: Emit "checkpoint skipped because system is idle" message at LOG level if log_checkpoints is set

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

In response to

Browse pgsql-hackers by date

  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