Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tqIqX-002gUa-So for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Mar 2025 21:33:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tqIqV-009tG3-5P for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Mar 2025 21:33:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tqIqU-009tFu-Co for pgsql-hackers@lists.postgresql.org; Thu, 06 Mar 2025 21:33:34 +0000 Received: from fout-b8-smtp.messagingengine.com ([202.12.124.151]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tqIqR-001NT8-3B for pgsql-hackers@lists.postgresql.org; Thu, 06 Mar 2025 21:33:33 +0000 Received: from phl-compute-13.internal (phl-compute-13.phl.internal [10.202.2.53]) by mailfout.stl.internal (Postfix) with ESMTP id 2C6CB114011F; Thu, 6 Mar 2025 16:33:31 -0500 (EST) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-13.internal (MEProxy); Thu, 06 Mar 2025 16:33:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1741296811; x=1741383211; bh=7MMtBUAnwt NrvoZbqADiX4JekvTpunYkG7m2vEv/bN4=; b=WHsHnmC943WduZmAgiunq2r+bd vwmUbRZ32vqA6Jpzajxcl8j17h1VN6aqoQ2kYSpHa4fd9MlQiuorKKbr4RB6Qmwl gEr9JjEx4h5UNHJCLbYZfxX7pMZ+I4K08G77XdPRTWl4hpfV0/fJXpphFASkpjqi JnXfsA+7K9O7xr6e9XAYN+BTl+TcSQ6BwZGPSQyTqgb/isVk0BuIQTE5XuyyCV9T JZqoImQjbtvA2jkXEXzmuaJIl1Xh30LggnXm1vdIhTxeCsU+Mo8GXfG44dvp5Xg/ +JnGffSwUkhIUr/ODF4Im0dfWI3jy8KwRvLzZ6FOAhH4aXzKMQRy4uyUXpDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1741296811; x=1741383211; bh=7MMtBUAnwtNrvoZbqADiX4JekvTpunYkG7m 2vEv/bN4=; b=2QyEeYqFFn4DVtilJ5luPFsfMJ4mz7OXlc7PmEc3KAqN/khUPR1 69ukGY1mPZC+Mhht0DZRxqkCE1gxkigc5aXSYX9seuv8knVHMy6uDiGOrYjgMJ6v Taz879kVWDJ5SjMHqE45eLiYDU137pem9HLUTmf1DYVdux2kyTtdBSAk3s7G9sYc QdRdZFU317kcyP4EpMfns1su3xflGZmdYOx1+M4/OEzBulezx4qFR6RWGh9vZdfJ TTLGDS0HUQDiOmkfhCxh67wUhg5UjkuP8eQkDpsohb2cMQu2qJ0vSozbbwRW6/uN Bzymvd+MadKDTB2aiUbVuSYapsV3cmmQifQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddutdekkeegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgesrgdtreerredt tdenucfhrhhomhepfdfguhhlvghrucfvrghvvghirhgrfdcuoegvuhhlvghrsegvuhhlvg hrthhordgtohhmqeenucggtffrrghtthgvrhhnpeekheetvefggedtudevjeehjeffteeu vdfhfedtvdfgleektdfgfeektdfhheekvdenucffohhmrghinhepvghnthgvrhhprhhish gvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepvghulhgvrhesvghulhgvrhhtohdrtghomhdpnhgspghrtghpthhtohepfedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtoheprghlvhhhvghrrhgvsegrlhhvhhdrnhho qdhiphdrohhrghdprhgtphhtthhopegrnhgurhgvfiesughunhhslhgrnhgvrdhnvghtpd hrtghpthhtohepphhgshhqlhdqhhgrtghkvghrsheslhhishhtshdrphhoshhtghhrvghs qhhlrdhorhhg X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 8F9CF780068; Thu, 6 Mar 2025 16:33:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Thu, 06 Mar 2025 18:33:06 -0300 From: "Euler Taveira" To: "Andrew Dunstan" , "Alvaro Herrera" Cc: pgsql-hackers@lists.postgresql.org Message-Id: In-Reply-To: <001f81e3-2be8-46ad-9aee-1a761686712c@dunslane.net> References: <202502051851.2nvzh3a6ukzc@alvherre.pgsql> <313aa202-b5fa-4e3f-95d0-83425575c66d@app.fastmail.com> <001f81e3-2be8-46ad-9aee-1a761686712c@dunslane.net> Subject: Re: log_min_messages per backend type Content-Type: multipart/alternative; boundary=f42d718124d948c49327931105ced0a0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --f42d718124d948c49327931105ced0a0 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Mar 5, 2025, at 1:40 PM, Andrew Dunstan wrote: > Just bikeshedding a bit ... > > I'm not mad keen on this design. I think the value should be either a single setting like "WARNING" or a set of type:setting pairs. I agree that "all" is a bad name, but I think "default" would make sense. > One of my main concerns was a clear interface. I think "default" is less confusing than "all". Your suggestion about single or list is aligned with what Alvaro suggested. IIUC you are suggesting default:loglevel only if it is part of the list; the single loglevel shouldn't contain the backend type to keep the backward compatibility. The advantage of your proposal is that it make it clear what the fallback log level is. However, someone could be confused asking if the "default" is a valid backend type and if there is a difference between WARNING and default:WARNING (both is a fallback for non-specified backend type elements). -- Euler Taveira EDB https://www.enterprisedb.com/ --f42d718124d948c49327931105ced0a0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Mar 5, 2025, at 1:40 PM, Andrew Dunst= an wrote:

Jus= t bikeshedding a bit ...

I'm not mad keen on this design. I th= ink the value should be=0A either a single setting like "WARNING" o= r a set of type:setting=0A pairs. I agree that "all" is a bad name,= but I think "default"=0A would make sense.


One of my main concerns was a clear interface. I think = "default" is less
confusing than "all". Your suggestion ab= out single or list is aligned with what
Alvaro suggested. IIUC you are suggesting default:lo= glevel only if it is part
of the list; the single loglevel shouldn't contain the backend typ= e to keep the
backwa= rd compatibility. The advantage of your proposal is that it make it clea= r
what the fallback = log level is. However, someone could be confused asking if
the "default" is a valid backend = type and if there is a difference between
WARNING and default:WARNING (both is a fallback fo= r non-specified backend type
elements).


--
Euler Taveira

--f42d718124d948c49327931105ced0a0--