> 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 t
On Wed, Dec 29, 2021 at 10:40:59AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> >> Therefore, reporting the checkpoint progress in the server logs, much
> >> like [1], seems to be the best way IMO.
>
> > I find progress reporting in the logfile to generally be a terrible
> > way of doing th
On Wed, Dec 29, 2021 at 10:40:59AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
>> I think the right choice to solve the *general* problem is the
>> mentioned pg_stat_progress_checkpoints.
>
> +1
Agreed. I don't see why this would not work as there are
PgBackendStatus entries for each auxil
Coincidentally, I was thinking about the same yesterday after tired of
waiting for the checkpoint completion on a server.
On Wed, Dec 29, 2021 at 7:41 AM Tom Lane wrote:
> Magnus Hagander writes:
> >> Therefore, reporting the checkpoint progress in the server logs, much
> >> like [1], seems t
Magnus Hagander writes:
>> Therefore, reporting the checkpoint progress in the server logs, much
>> like [1], seems to be the best way IMO.
> 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 b
On Wed, Dec 29, 2021 at 3:31 PM Bharath Rupireddy
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 log
