Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
Date
Msg-id 20220309141750.jirvp5o5v5zpr4lz@jrouhaud
Whole thread Raw
In response to Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)  (Nitin Jadhav <nitinjadhavpostgres@gmail.com>)
Responses Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)  (Nitin Jadhav <nitinjadhavpostgres@gmail.com>)
List pgsql-hackers
On Tue, Mar 08, 2022 at 08:57:23PM +0530, Nitin Jadhav wrote:
> 
> I just wanted to avoid extra calculations just to show the progress in
> the view. Since it's a good metric, I have added an additional field
> named 'next_flags' to the view which holds all possible flag values of
> the next checkpoint.

I still don't think that's ok.  IIUC the only way to know if the current
checkpoint is throttled or not is to be aware that the "next_flags" can apply
to the current checkpoint too, look for it and see if that changes the
semantics of what the view say the current checkpoint is.  Most users will get
it wrong.

> This gives more information than just saying
> whether the new checkpoint is requested or not with the same memory.

So that next_flags will be empty most of the time?  It seems confusing.

Again I would just display a bool flag saying whether a new checkpoint has been
explicitly requested or not, it seems enough.

If you're interested in that next checkpoint, you probably want a quick
completion of the current checkpoint first (and thus need to know if it's
throttled or not).  And then you will have to keep monitoring that view for the
next checkpoint anyway, and at that point the view will show the relevant
information.



pgsql-hackers by date:

Previous
From: "Daniel Westermann (DWE)"
Date:
Subject: Re: Changing "Hot Standby" to "hot standby"
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Optionally automatically disable logical replication subscriptions on error