Re: Generalize ereport_startup_progress infrastructure

On Wed, Aug 10, 2022 at 6:21 PM Nitin Jadhav
<nitinjadhavpostgres(at)gmail(dot)com> wrote:
>
> Given two options, option-1 is to use a single GUC across all kind of
> log running operations and option-2 is to use multiple GUCs (one for
> each kind of long running operations), I go with option-1 because if a
> user is interested to see a log message after every 10s for startup
> operations (or any other long running operations) then it is likely
> that he is interested to see other long running operations after every
> 10s only. It does not make sense to use different intervals for each
> kind of long running operation here. It also increases the number of
> GUCs which makes things complex. So it is a good idea to use a single
> GUC here.

+1.

> But I am worried about the on/off switch as Robert
> mentioned.

Are you worried that users might want to switch off the progress
report messages at process level, for instance, they want to log the
startup process' long running operations progress but not, say,
checkpointer or postmaster? IMO, a long running operation, if it is
happening in any of the processes, is a concern for the users and
having progress report log messages for them would help users debug
any issues or improve observability of the server as a whole. With
single GUC, the server log might contain progress reports of all the
long running (wherever we use this ereport_progress()) operations in
the entire server's lifecycle, which isn't bad IMO.

I'd still vote for a single GUC log_progress_report_interval without
worrying much about process-level enable/disable capability. However,
let's hear what other hackers think about this.

--
Bharath Rupireddy
RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/