On Fri, Mar 15, 2019 at 12:55:36PM +0300, Sergei Kornilov wrote: > We have INFO ereport messages in alter table attach partition like this: > > partition constraint for table \"%s\" is implied by existing constraints > > So now I am +1 to idea of change error level for this messages. I attach > patch to lower such ereport to DEBUG1 level
+1 I reviewed existing logging behavior and now I agree. Also, I wondered if it was worth considering a way to configure logging which scales better than boolean GUCs: log_duration log_checkpoints log_(dis)connections log_lock_waits log_replication_commands ..plus a bunch more developer ones: https://www.postgresql.org/docs/current/runtime-config-developer.html I'm (very tentatively) thinking of a string GUC which is split on whitespace and is parsed into a bitmap which is consulted instead of the existing vars, as in: if (logging_bits & LOG_CHECKPOINTS) ... which could be either an enum or #define.. If there's an entry in logging_bits which isn't recognized, I guess it'd be logged at NOTICE or WARNING. I'd also request this be conditional promoted from DEBUG1 to LOG depending a new logging_bit for LOG_PARALLEL_WORKER: |starting background worker process "parallel worker for PID... When written to csvlog (and when using log_min_error_severity=notice or similar), that would help answering questions like: "what queries are my max_parallel_workers(_per_process) being used for (at the possible exclusion of other queries)?". I noticed on our servers that a query running possibly every ~10sec had been using parallel query, which not only hurt that query, but also meant that works may have been unavailable for report queries which could have benefited from their use. It'd be nice to know if there were other such issues. Justin