On Tue, Dec 07, 2021 at 11:18:37PM +0100, Tomas Vondra wrote: > On 12/7/21 15:36, Bharath Rupireddy wrote: > > Currently one can know the kind of on-going/last checkpoint (shutdown, > > end-of-recovery, immediate, force etc.) only via server logs that to > > when log_checkpoints GUC is on.
> > The checkpoint info can be obtained from the control file (either by > > pg_control_checkpoint() or by pg_controldata tool) whereas checkpoint kind > > isn't available there. > > How about we add an extra string field to the control file alongside > > the other checkpoint info it already has? This way, the existing > > pg_control_checkpoint() or pg_controldata tool can easily be enhanced > > to show the checkpoint kind as well. One concern is that we don't want > > to increase the size of pg_controldata by more than the typical block > > size (of 8K) to avoid any torn-writes. With this change, we might add > > at max the strings specified at [1]. Adding it to the control file has > > an advantage of preserving the last checkpoint kind which might be > > useful. > > [1] for checkpoint: "checkpoint shutdown end-of-recovery immediate > > force wait wal time flush-all" > > for restartpoint: "restartpoint shutdown end-of-recovery immediate > > force wait wal time flush-all" > > I'd bet squashing all of this into a single string (not really a flag) > will just mean people will have to parse it, etc. Keeping individual > boolean flags (or even separate string fields) would be better, I guess. Since the size of controldata is a concern, I suggest to add an int16 to populate with flags, which pg_controldata can parse for display. Note that this other patch intends to add the timestamp and LSN of most recent recovery to controldata. https://commitfest.postgresql.org/36/3183/ > We already have some checkpoint info in pg_stat_bgwriter, but that's > just aggregated data, not very convenient for info about the current > checkpoint. So maybe we should add pg_stat_progress_checkpoint, showing > various info about the current checkpoint? It could go into the pg_stat_checkpointer view, which would be the culmination of another patch (cc Melanie). https://commitfest.postgresql.org/36/3272/ -- Justin