On Wed, Dec 8, 2021 at 7:43 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Wed, Dec 8, 2021 at 7:34 AM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
> > >> I agree it might be useful to provide information about the nature of
> > >> the checkpoint, and perhaps even PID of the backend that triggered it
> > >> (although that may be tricky, if the backend terminates).
> >
> > >> I'm not sure about adding it to control data, though. That doesn't seem
> > >> like a very good match for something that's mostly for monitoring.
> > >
> > > Having it in the control data file (along with the existing checkpoint
> > > information) will be helpful to know what was the last checkpoint
> > > information and we can use the existing pg_control_checkpoint function
> > > or the tool to emit that info. I plan to add an int16 flag as
> > > suggested by Justin in this thread and come up with a patch.
> > >
> > OK, although I'm not sure it's all that useful (if we have that in some
> > sort of system view).
>
> If the server is down, the control file will help. Since we already
> have the other checkpoint info in the control file, it's much more
> useful and sensible to have this extra piece of missing information
> (checkpoint kind) there.
Here's the patch that adds the last checkpoint kind to the control
file, displayed as an output in the pg_controldata tool and also
exposes it via the pg_control_checkpoint function.
I will analyze and work on the idea of pg_stat_progress_checkpoint and
try to post the patch here in this thread.
Regards,
Bharath Rupireddy.