Re: Generalize ereport_startup_progress infrastructure

Hi,

On 8/2/22 8:40 PM, Robert Haas wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> 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.

+1 on the idea to generalize this infrastructure in other places.

I also doubt about having one single GUC to control all the places: What
about adding in the patch the calls to the new API where you think it
could be useful too? (and in the same time make use of dedicated GUC(s)
where it makes sense?)

Regards,

--

Bertrand Drouvot
Amazon Web Services: https://aws.amazon.com