On Mon, Feb 28, 2022 at 06:03:54PM +0530, Bharath Rupireddy wrote: > On Mon, Feb 28, 2022 at 12:02 PM Julien Rouhaud <rjuju...@gmail.com> wrote: > > > > I suggested upthread to store the starting timeline instead. This way you > > can > > deduce whether it's a restartpoint or a checkpoint, but you can also deduce > > other information, like what was the starting WAL. > > I don't understand why we need the timeline here to just determine > whether it's a restartpoint or checkpoint.
I'm not saying it's necessary, I'm saying that for the same space usage we can store something a bit more useful. If no one cares about having the starting timeline available for no extra cost then sure, let's just store the kind directly. > Can't the checkpoint start LSN be deduced from > PROGRESS_CHECKPOINT_LSN, checkPoint.redo? I'm not sure I'm following, isn't checkPoint.redo the checkpoint start LSN? > > As mentioned upthread, there can be multiple backends that request a > > checkpoint, so unless we want to store an array of pid we should store a > > number > > of backend that are waiting for a new checkpoint. > > Yeah, you are right. Let's not go that path and store an array of > pids. I don't see a strong use-case with the pid of the process > requesting checkpoint. If required, we can add it later once the > pg_stat_progress_checkpoint view gets in. I don't think that's really necessary to give the pid list. If you requested a new checkpoint, it doesn't matter if it's only your backend that triggered it, another backend or a few other dozen, the result will be the same and you have the information that the request has been seen. We could store just a bool for that but having a number instead also gives a bit more information and may allow you to detect some broken logic on your client code if it keeps increasing.