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

From Nitin Jadhav
Subject Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
Date
Msg-id CAMm1aWZP8brtPB9MitarD_cB_HD_n2fkmH2rHijA-ivRWOfN=w@mail.gmail.com
Whole thread Raw
In response to Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
List pgsql-hackers
> > 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.
>
> Again I would just display a bool flag saying whether a new checkpoint has been
> explicitly requested or not, it seems enough.

Ok. I agree that it is difficult to interpret it correctly. So even if
say that a new checkpoint has been explicitly requested, the user may
not understand that it affects current checkpoint behaviour unless the
user knows the internals of the checkpoint. How about naming the field
to 'throttled' (Yes/ No) since our objective is to show that the
current checkpoint is throttled or not.

Thanks & Regards,
Nitin Jadhav

On Wed, Mar 9, 2022 at 7:48 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> 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: Nitin Jadhav
Date:
Subject: Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
Next
From: Yura Sokolov
Date:
Subject: Re: BufferAlloc: don't take two simultaneous locks