Re: Change ereport level for QueuePartitionConstraintValidation

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