Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
От | Nitin Jadhav |
---|---|
Тема | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) |
Дата | |
Msg-id | CAMm1aWb=0aWAMuvD-H60h2AhjCKPLfRqCG4zOURj2RPcyuLZmA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
(Julien Rouhaud <rjuju123@gmail.com>)
|
Список | pgsql-hackers |
> > > > > 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.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Nitin JadhavДата:
Сообщение: Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)