On Wed, Dec 8, 2021 at 4:07 AM Justin Pryzby <pry...@telsasoft.com> wrote: > > 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.
+1. I will come up with a patch soon. > Note that this other patch intends to add the timestamp and LSN of most recent > recovery to controldata. > https://commitfest.postgresql.org/36/3183/ Thanks. I will go through it separately. > > 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/ +1 to have pg_stat_progress_checkpoint view. We have CheckpointStatsData already. What we need is to make this structure shared and add a little more info to represent the progress, so that the other backends can access it. I think we can discuss this in a separate thread to give it a fresh try rather than proposing this as a part of another thread. I will spend some time on pg_stat_progress_checkpoint proposal and try to come up with a separate thread to discuss. Regards, Bharath Rupireddy.
