> > > > > 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.
> >
> > It's a good metric to show in the view but the information is not
> > readily available. Additional code is required to calculate the number
> > of requests. Is it worth doing that? I feel this can be added later if
> > required.
>
> Is it that hard or costly to do? Just sending a message to increment
> the stat counter in RequestCheckpoint() would be enough.
>
> Also, unless I'm missing something it's still only showing the initial
> checkpoint flags, so it's *not* showing what the checkpoint is really
> doing, only what the checkpoint may be doing if nothing else happens.
> It just feels wrong. You could even use that ckpt_flags info to know
> that at least one backend has requested a new checkpoint, if you don't
> want to have a number of backends.
I just wanted to avoid extra calculations just to show the progress in
the view. Since it's a good metric, I have added an additional field
named 'next_flags' to the view which holds all possible flag values of
the next checkpoint. This gives more information than just saying
whether the new checkpoint is requested or not with the same memory. I
am updating the progress of 'next_flags' in
ImmediateCheckpointRequested() which gets called during buffer write
phase. I gave a thought to update the progress in other places also
but I feel updating in ImmediateCheckpointRequested() is enough as the
current checkpoint behaviour gets affected by only
CHECKPOINT_IMMEDIATE flag and all other checkpoint requests done in
case of createdb(), dropdb(), etc gets called with
CHECKPOINT_IMMEDIATE flag. I have updated this in the v5 patch. Please
share your thoughts.
Thanks & Regards,
Nitin Jadhav
On Thu, Mar 3, 2022 at 11:58 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Wed, Mar 2, 2022 at 7:15 PM Nitin Jadhav
> <nitinjadhavpostgres@gmail.com> wrote:
> >
> > > > > 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.
> >
> > It's a good metric to show in the view but the information is not
> > readily available. Additional code is required to calculate the number
> > of requests. Is it worth doing that? I feel this can be added later if
> > required.
>
> Is it that hard or costly to do? Just sending a message to increment
> the stat counter in RequestCheckpoint() would be enough.
>
> Also, unless I'm missing something it's still only showing the initial
> checkpoint flags, so it's *not* showing what the checkpoint is really
> doing, only what the checkpoint may be doing if nothing else happens.
> It just feels wrong. You could even use that ckpt_flags info to know
> that at least one backend has requested a new checkpoint, if you don't
> want to have a number of backends.
