From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Generalize ereport_startup_progress infrastructure |
Date: | 2022-08-02 18:40:56 |
Message-ID: | CA+TgmoYzLghD0wG5DNNmmT366ejUxXKds0LkLj5gaWJk47PiQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 2, 2022 at 3:25 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2022-08-02 18:42:03 | Re: Add LZ4 compression in pg_dump |
Previous Message | Jacob Champion | 2022-08-02 18:27:33 | Re: Finer grain log timestamps |