On Thu, Dec 9, 2021 at 12:08 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > 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.
Here's v2, rebased onto the latest master. Regards, Bharath Rupireddy.
v2-0001-add-last-checkpoint-kind-to-pg_control-file.patch
Description: Binary data
