Change ereport level for QueuePartitionConstraintValidation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Change ereport level for QueuePartitionConstraintValidation

Sergei Kornilov
Hello

Per discussion started here: https://www.postgresql.org/message-id/CA%2BTgmoZWSLUjVcc9KBSVvbn%3DU5QRgW1O-MgUX0y5CnLZOA2qyQ%40mail.gmail.com

We have INFO ereport messages in alter table attach partition like this:
> partition constraint for table \"%s\" is implied by existing constraints

Personally I like this message and not want remove it.
But recently my colleague noticed that INFO level is written to stderr by psql. For example, simple command

> psql -c "alter table measurement attach partition measurement_y2006m04 for values from ('2006-04-01') to ('2006-05-01');"

can produce stderr output like error, but this is expected behavior from successful execution.

And INFO level always sent to client regardless of client_min_messages as clearly documented in src/include/utils/elog.h

So now I am +1 to idea of change error level for this messages. I attach patch to lower such ereport to DEBUG1 level

thanks

PS: possible we can change level to NOTICE but I doubt we will choose this way

regards, Sergei

lowering_partition_constraint_check_ereport_level.patch (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Change ereport level for QueuePartitionConstraintValidation

Justin Pryzby
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