Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
От | Matthias van de Meent |
---|---|
Тема | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) |
Дата | |
Msg-id | CAEze2WhBpaVBMruRyih5UtnDbZMfYwXouxrW7cOWtuNA5o0xiw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) (Nitin Jadhav <nitinjadhavpostgres@gmail.com>) |
Список | pgsql-hackers |
On Tue, 15 Feb 2022 at 13:16, Nitin Jadhav <nitinjadhavpostgres@gmail.com> wrote: > > > Apart from above fields, I am planning to add few more fields to the > > view in the next patch. That is, process ID of the backend process > > which triggered a CHECKPOINT command, checkpoint start location, filed > > to indicate whether it is a checkpoint or restartpoint and elapsed > > time of the checkpoint operation. Please share your thoughts. I would > > be happy to add any other information that contributes to showing the > > progress of checkpoint. > > The progress reporting mechanism of postgres uses the > 'st_progress_param' array of 'PgBackendStatus' structure to hold the > information related to the progress. There is a function > 'pgstat_progress_update_param()' which takes 'index' and 'val' as > arguments and updates the 'val' to corresponding 'index' in the > 'st_progress_param' array. This mechanism works fine when all the > progress information is of type integer as the data type of > 'st_progress_param' is of type integer. If the progress data is of > different type than integer, then there is no easy way to do so. Progress parameters are int64, so all of the new 'checkpoint start location' (lsn = uint64), 'triggering backend PID' (int), 'elapsed time' (store as start time in stat_progress, timestamp fits in 64 bits) and 'checkpoint or restartpoint?' (boolean) would each fit in a current stat_progress parameter. Some processing would be required at the view, but that's not impossible to overcome. Kind regards, Matthias van de Meent
В списке pgsql-hackers по дате отправления: