Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)

From: Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
Date: 2022-03-11 09:11:23
Message-ID: CAMm1aWZP8brtPB9MitarD_cB_HD_n2fkmH2rHijA-ivRWOfN=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yura Sokolov 2022-03-11 09:34:32 Re: BufferAlloc: don't take two simultaneous locks
Previous Message Nitin Jadhav 2022-03-11 08:47:59 Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)