On Wed, Dec 8, 2021 at 7:43 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > On Wed, Dec 8, 2021 at 7:34 AM Tomas Vondra > <tomas.von...@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.
v1-0001-add-last-checkpoint-kind-to-pg_control-file.patch
Description: Binary data
