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 20220228063222.rhmlwtdloeetibom@jrouhaud
Whole thread Raw
In response to Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
Hi,

On Mon, Feb 28, 2022 at 10:21:23AM +0530, Bharath Rupireddy wrote:
> 
> Another thought for my review comment:
> > 1) Can't we use pg_is_in_recovery to determine if it's a restartpoint
> > or checkpoint instead of having a new function
> > pg_stat_get_progress_checkpoint_type?
> 
> I don't think using pg_is_in_recovery work here as it is taken after
> the checkpoint has started. So, I think the right way here is to send
> 1 in CreateCheckPoint  and 2 in CreateRestartPoint and use
> CASE-WHEN-ELSE-END to show "1": "checkpoint" "2":"restartpoint".

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.

> 11) I think it's discussed, are we going to add the pid of the
> checkpoint requestor?

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.



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: generic plans and "initial" pruning
Next
From: Peter Eisentraut
Date:
Subject: Re: parse/analyze API refactoring