Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display

On Fri, Dec 24, 2021 at 08:04:08PM +0530, Bharath Rupireddy wrote:
> On Fri, Dec 24, 2021 at 7:19 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > On Sun, Dec 12, 2021 at 06:08:05PM +0530, Bharath Rupireddy wrote:
> > > Another idea could be to use the infrastructure laid out by the commit
> > > 9ce346e [1]. With ereport_startup_progress, we can emit the LOGs(of
> > > current recovering WAL file) for every log_startup_progress_interval
> > > seconds/milliseconds.
> > >
> > > One problem is that ereport_startup_progress doesn't work on
> > > StandbyMode, maybe we can remove this restriction unless we have a
> > > major reason for not allowing it on the standby.
> > > /* Prepare to report progress of the redo phase. */
> > > if (!StandbyMode)
> > > begin_startup_progress_phase();
> >
> > The relevant conversation starts here.
> > https://www.postgresql.org/message-id/20210814214700.GO10479%40telsasoft.com
> >
> > There was a lot of confusion in that thread, though.
> >
> > The understanding was that it didn't make sense for that feature to
> > continuously log messages on a standby (every 10sec by default). That seems
> > like too much - the issue of a checkpointed logged every 5min was enough of a
> > hurdle.
> >
> > If you're talking about a new feature that uses the infrastructre from 9ce3,
> > but is controlled by a separate GUC like log_wal_traffic, that could be okay.
>
> Do you see any problems using the same GUC
> log_startup_progress_interval and ereport_startup_progress API
> introduced by 9ce346e? I prefer this instead of a new GUC. Thoughts?

I referenced the thread where we avoided writing progress logs during normal
operation of a standby, since the logs would be both useless and excessive.

If your patch were to use the same infrastructure, you'd still want to avoid
disturbing that behavior and writing useless logs.

--
Justin