On Wed, Dec 29, 2021 at 3:31 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> At times, some of the checkpoint operations such as removing old WAL
> files, dealing with replication snapshot or mapping files etc. may
> take a while during which the server doesn't emit any logs or
> information, the only logs emitted are LogCheckpointStart and
> LogCheckpointEnd. Many times this isn't a problem if the checkpoint is
> quicker, but there can be extreme situations which require the users
> to know what's going on with the current checkpoint.
>
> Given that the commit 9ce346ea [1] introduced a nice mechanism to
> report the long running operations of the startup process in the
> server logs, I'm thinking we can have a similar progress mechanism for
> the checkpoint as well. There's another idea suggested in a couple of
> other threads to have a pg_stat_progress_checkpoint similar to
> pg_stat_progress_analyze/vacuum/etc. But the problem with this idea is
> during the end-of-recovery or shutdown checkpoints, the
> pg_stat_progress_checkpoint view isn't accessible as it requires a
> connection to the server which isn't allowed.
>
> Therefore, reporting the checkpoint progress in the server logs, much
> like [1], seems to be the best way IMO. We can 1) either make
> ereport_startup_progress and log_startup_progress_interval more
> generic (something like ereport_log_progress and
> log_progress_interval), move the code to elog.c, use it for
> checkpoint progress and if required for other time-consuming
> operations 2) or have an entirely different GUC and API for checkpoint
> progress.
>
> IMO, option (1) i.e. ereport_log_progress and log_progress_interval
> (better names are welcome) seems a better idea.
>
> Thoughts?
I find progress reporting in the logfile to generally be a terrible
way of doing things, and the fact that we do it for the startup
process is/should be only because we have no other choice, not because
it's the right choice.
I think the right choice to solve the *general* problem is the
mentioned pg_stat_progress_checkpoints.
We may want to *additionally* have the ability to log the progress
specifically for the special cases when we're not able to use that
view. And in those case, we can perhaps just use the existing
log_startup_progress_interval parameter for this as well -- at least
for the startup checkpoint.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/