Hi,
On Thu, Feb 17, 2022 at 10:39:02PM +0530, Nitin Jadhav wrote:
> > > Thank you for sharing the information. 'triggering backend PID' (int)
> > > - can be stored without any problem.
> >
> > There can be multiple processes triggering a checkpoint, or at least wanting it
> > to happen or happen faster.
>
> Yes. There can be multiple processes but there will be one checkpoint
> operation at a time. So the backend PID corresponds to the current
> checkpoint operation. Let me know if I am missing something.
If there's a checkpoint timed triggered and then someone calls
pg_start_backup() which then wait for the end of the current checkpoint
(possibly after changing the flags), I think the view should reflect that in
some way. Maybe storing an array of (pid, flags) is too much, but at least a
counter with the number of processes actively waiting for the end of the
checkpoint.
> > > 'checkpoint or restartpoint?'
> >
> > Do you actually need to store that? Can't it be inferred from
> > pg_is_in_recovery()?
>
> AFAIK we cannot use pg_is_in_recovery() to predict whether it is a
> checkpoint or restartpoint because if the system exits from recovery
> mode during restartpoint then any query to pg_stat_progress_checkpoint
> view will return it as a checkpoint which is ideally not correct. Please
> correct me if I am wrong.
Recovery ends with an end-of-recovery checkpoint that has to finish before the
promotion can happen, so I don't think that a restart can still be in progress
if pg_is_in_recovery() returns false.