Re: Generalize ereport_startup_progress infrastructure - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Generalize ereport_startup_progress infrastructure
Date
Msg-id CA+TgmoYzLghD0wG5DNNmmT366ejUxXKds0LkLj5gaWJk47PiQw@mail.gmail.com
Whole thread Raw
In response to Generalize ereport_startup_progress infrastructure  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Generalize ereport_startup_progress infrastructure
Re: Generalize ereport_startup_progress infrastructure
List pgsql-hackers
On Tue, Aug 2, 2022 at 3:25 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> ereport_startup_progress infrastructure added by commit 9ce346e [1]
> will be super-useful for reporting progress of any long-running server
> operations, not just the startup process operations. For instance,
> postmaster can use it for reporting progress of temp file and temp
> relation file removals [2], checkpointer can use it for reporting
> progress of snapshot or mapping file processing or even WAL file
> processing and so on. And I'm sure there can be many places in the
> code where we have while or for loops which can, at times, take a long
> time to finish and having a log message there would definitely help.
>
> Here's an attempt to generalize the ereport_startup_progress
> infrastructure. The attached v1 patch places the code in elog.c/.h,
> renames associated functions and variables, something like
> ereport_startup_progress to ereport_progress,
> log_startup_progress_interval to log_progress_report_interval and so
> on.

I'm not averse to reusing this infrastructure in other places, but I
doubt we'd want all of those places to be controlled by a single GUC,
especially because that GUC is also the on/off switch for the feature.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Finer grain log timestamps
Next
From: Jacob Champion
Date:
Subject: Re: Add LZ4 compression in pg_dump