On Wed, Aug 10, 2022 at 6:21 PM Nitin Jadhav <nitinjadhavpostg...@gmail.com> wrote: > > Given two options, option-1 is to use a single GUC across all kind of > log running operations and option-2 is to use multiple GUCs (one for > each kind of long running operations), I go with option-1 because if a > user is interested to see a log message after every 10s for startup > operations (or any other long running operations) then it is likely > that he is interested to see other long running operations after every > 10s only. It does not make sense to use different intervals for each > kind of long running operation here. It also increases the number of > GUCs which makes things complex. So it is a good idea to use a single > GUC here.
+1. > But I am worried about the on/off switch as Robert > mentioned. Are you worried that users might want to switch off the progress report messages at process level, for instance, they want to log the startup process' long running operations progress but not, say, checkpointer or postmaster? IMO, a long running operation, if it is happening in any of the processes, is a concern for the users and having progress report log messages for them would help users debug any issues or improve observability of the server as a whole. With single GUC, the server log might contain progress reports of all the long running (wherever we use this ereport_progress()) operations in the entire server's lifecycle, which isn't bad IMO. I'd still vote for a single GUC log_progress_report_interval without worrying much about process-level enable/disable capability. However, let's hear what other hackers think about this. -- Bharath Rupireddy RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/
