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

On Mon, Feb 28, 2022 at 06:03:54PM +0530, Bharath Rupireddy wrote:
> On Mon, Feb 28, 2022 at 12:02 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> >
> > I suggested upthread to store the starting timeline instead. This way you can
> > deduce whether it's a restartpoint or a checkpoint, but you can also deduce
> > other information, like what was the starting WAL.
>
> I don't understand why we need the timeline here to just determine
> whether it's a restartpoint or checkpoint.

I'm not saying it's necessary, I'm saying that for the same space usage we can
store something a bit more useful. If no one cares about having the starting
timeline available for no extra cost then sure, let's just store the kind
directly.

> Can't the checkpoint start LSN be deduced from
> PROGRESS_CHECKPOINT_LSN, checkPoint.redo?

I'm not sure I'm following, isn't checkPoint.redo the checkpoint start LSN?

> > As mentioned upthread, there can be multiple backends that request a
> > checkpoint, so unless we want to store an array of pid we should store a number
> > of backend that are waiting for a new checkpoint.
>
> Yeah, you are right. Let's not go that path and store an array of
> pids. I don't see a strong use-case with the pid of the process
> requesting checkpoint. If required, we can add it later once the
> pg_stat_progress_checkpoint view gets in.

I don't think that's really necessary to give the pid list.

If you requested a new checkpoint, it doesn't matter if it's only your backend
that triggered it, another backend or a few other dozen, the result will be the
same and you have the information that the request has been seen. We could
store just a bool for that but having a number instead also gives a bit more
information and may allow you to detect some broken logic on your client code
if it keeps increasing.