Re: Generalize ereport_startup_progress infrastructure

On Wed, Aug 17, 2022 at 4:30 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> As I explained upthread [1], I'd vote for a single GUC at the entire
> server level. If the users/customers request per-process or
> per-operation progress report GUCs, we can then consider it.

Well, I don't agree that either of the proposed new uses of this
infrastructure are the right way to solve the problems in question, so
worrying about how to name the GUCs when we have a bunch of uses of
this infrastructure seems to me to be premature. The proposed use in
the postmaster doesn't look very safe, so you either need to give up
on that or figure out a way to make it safe. The proposed use in the
checkpointer looks like it needs more design work, because it's not
clear whether or how it should interact with log_checkpoints. While I
agree that changing log_checkpoints into an integer value doesn't
necessarily make sense, having some kind of new checkpoint logging
that is completely unrelated to existing checkpoint logging doesn't
necessarily make sense to me either.

I do have some sympathy with the idea that if people care about
operations that unexpectedly run for a long time, they probably care
about all of them, and probably don't care about changing the timeout
or even the enable switch for each one individually. Honestly, it's
not very clear to me who would want to ever turn off the startup
progress stuff, or why they'd want to change the interval. I added a
GUC for it out of an abundance of caution, but I don't know why you'd
really want a different setting. Maybe there's some reason, but it's
not clear to me. At the same time, I don't think the overall picture
here is too clear yet. I'm reluctant to commit to a specific UI for a
feature whose scope we don't seem to know.

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