Re: Change ereport level for QueuePartitionConstraintValidation

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Sergei Kornilov <sk@zsrv.org>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Amit Langote <langote_amit_f8@lab.ntt.co.jp>, Robert Haas <robertmhaas@gmail.com>
Date: 2019-07-23T16:35:59Z
Lists: pgsql-hackers
On 2019-Jul-23, David Rowley wrote:

> Also, if I'm not wrong, the votes so far appear to be:
> 
> NOTICE:  Robert, Amit
> DEBUG1: Tom, Alvaro (I'm entirely basing this on the fact that they
> mentioned possible ways to test with DEBUG1)
> 
> I'll be happy with DEBUG1 if we can get tests to test it.

Well, I think the user doesn't *care* to see a message about the
optimization.  They just want the command to be fast.  *We* (developers)
want the message in order to ensure the command remains fast.  So some
DEBUG level seems the right thing.

Another way to reach the same conclusion is to think about the "building
index ... serially" messages, which are are pretty much in the same
category and are using DEBUG1.  (I do think the TOAST ones are just
noise though, and since they disrupt potential testing with
client_min_messages=debug1, another way to go about this is to reduce
those to DEBUG2 or just elide them.)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Commits

  1. Avoid using INFO elevel for what are fundamentally debug messages.

  2. Revert setting client_min_messages to 'debug1' in new tests.