Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
От | Bharath Rupireddy |
---|---|
Тема | Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display |
Дата | |
Msg-id | CALj2ACUWhAvV2_MA944jHL_iBWxApGWOa=r-CNWkycgzJR_NWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Список | pgsql-hackers |
On Fri, Dec 24, 2021 at 7:19 PM Justin Pryzby <pryzby@telsasoft.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? Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: