On Wed, Aug 17, 2022 at 4:30 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.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
