Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4AcW-00070O-33 for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Mar 2019 20:37:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h4AcU-000241-Gf for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Mar 2019 20:36:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4AcU-00021D-5h for pgsql-hackers@lists.postgresql.org; Wed, 13 Mar 2019 20:36:58 +0000 Received: from mail-io1-xd43.google.com ([2607:f8b0:4864:20::d43]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4AcQ-0001V7-JL for pgsql-hackers@postgresql.org; Wed, 13 Mar 2019 20:36:57 +0000 Received: by mail-io1-xd43.google.com with SMTP id p17so2943080iol.7 for ; Wed, 13 Mar 2019 13:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to:user-agent; bh=I6kP3T4/UDCMfpRCtwZYHIt7Hc9SAdqDr5qI2VdvAjo=; b=YE2M+YrgBSXwNai96+Hdmamk24SySrmPix6I4xQ2RRj5/KMv+YZC3ngBZSnlxH+0Qm QZC/RWrX+JKhj+Kh68OEVwaO/Vw3mtzGPTlP0HZhQwxqY0MPmykjco9dM7r87kUh/ajC xCs8RWqKJvYaDGgN7FzGoXSrbI9o8nAxqldDKnS2bK7a8Qex0s/jOYfZmup7hOfBVyRt DuoA6aRovCcaKsvLtIGJ7uFEiAbscGazPw0h09eOI8j3Dy5xqac6/NLtexZLtSIBDOWr +l03PwaR4/0srpRamGDH4v6Ij3D+FXNyl08WS5Ri6tn4NX0O6JpqG/E9o4oXCkuPJktb HVfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to:user-agent; bh=I6kP3T4/UDCMfpRCtwZYHIt7Hc9SAdqDr5qI2VdvAjo=; b=Cq09fN0mgQYBk8ndNP5HDb6LIBDmQn3B31uigVCeydu9ft3QGRx3raT1lRvnboQ8Vk UwcmsrLplrC2dOcau82YIYDnwOvJMhrAxiQSW4eqCV8II0fLy7j3nBPnIfABvrCelwpU 1YQ0+uBXI1BQMGSkoiOXtaOnsgVBi1BuTmBfC/zTejBPfhfFa6EWXinPIXRQ6GXVW44l Gz3NvyMUNiEFtbM927aXhDzKyPdEgnYjxOiAPixAxfJ9Gg8Xqb90JIBo4jN6agwrF0fO WNXna3IfR6t+jY9+dXouRPvGQEuy/NsBpuX3fJLDY7vDYrovJZpNM/+nLydOL7oAI26E JfuQ== X-Gm-Message-State: APjAAAWIIldHVGcbLpywDfXD+N7FDcW7JUAqLEEPTcMogn8EyAZyaqqi V8RkAaW5dDdxrx9a4LMbTMjncA== X-Google-Smtp-Source: APXvYqyAjU1RgJGMegvk4aUhuUABv5GryE5JITLjBH/bqrRKOPpOoBx60DIIkd4Z/BZId2kQgfXzhg== X-Received: by 2002:a5e:c30a:: with SMTP id a10mr15825501iok.193.1552509412406; Wed, 13 Mar 2019 13:36:52 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id o129sm102269ito.0.2019.03.13.13.36.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Mar 2019 13:36:51 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 306A8800B7B; Wed, 13 Mar 2019 15:36:50 -0500 (CDT) Date: Wed, 13 Mar 2019 15:36:50 -0500 From: Justin Pryzby To: Tom Lane , Robert Haas Cc: Sergei Kornilov , David Rowley , PostgreSQL mailing lists , Alvaro Herrera , Stephen Frost , Ildar Musin Subject: Re: using index or check in ALTER TABLE SET NOT NULL Message-ID: <20190313203650.GS23597@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7254.1552496972@sss.pgh.pa.us> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On Wed, Mar 13, 2019 at 01:25:11PM -0400, Robert Haas wrote: > On Wed, Mar 13, 2019 at 1:19 PM Tom Lane wrote: > > Oh, and yes, I think QueuePartitionConstraintValidation's usage > > is an unacceptable abuse of INFO level. I'm surprised we haven't > > gotten complaints about it yet. > > Perhaps that's because users aren't as direly opposed to informational > messages from DDL commands as you seem to believe... On Wed, Mar 13, 2019 at 01:09:32PM -0400, Tom Lane wrote: > Sergei Kornilov writes: > >> Ugh, I guess so. Or how about changing the message itself to use > >> INFO, like we already do in QueuePartitionConstraintValidation? > > > Fine for me. But year ago this was implemented in my patch and Tom voted against using INFO level for such purpose: https://www.postgresql.org/message-id/1142.1520362313%40sss.pgh.pa.us > > What I thought then was that you didn't need the message at all, > at any debug level. I still think that. It might have been useful > for development purposes but it does not belong in committed code. > INFO (making it impossible for anybody to not have the message > in-their-face) is right out. I'm writing to provide a datapoint for the existing message regarding "implied by existing constraints" in QueuePartitionConstraintValidation. On the one hand, I agree that message at INFO is more verbose than other commands, and I'm 20% surprised by it. On the other hand, I *like* the output (including at INFO level). It alerted me to 1) deficiency with some of our tables (due to column not marked NOT NULL); and, 2) helped me to understand how to improve some of our dynamic DDL. If the message weren't visible at LOG, I'd miss it, at least sometimes, and look for how to re-enable it (but statement logging of DEBUG is beyond excessive). For context, I'm someone who configures servers with log_min_messages=info and who sometimes SETs client_min_messages='DEBUG1' ; I have $toomany warnings in our monitoring system, because I'd rather see twice as much stuff that may or may not be interesting than miss 10% of things I needed to see. Justin