On Thu, Dec 9, 2021 at 12:08 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> 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.
Here's v2, rebased onto the latest master.
Regards,
Bharath Rupireddy.