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 1tfkUh-004nWx-U6 for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Feb 2025 18:51:28 +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 1tfkUg-00HED8-S3 for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Feb 2025 18:51:26 +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 1tfkUg-00HECz-74 for pgsql-hackers@lists.postgresql.org; Wed, 05 Feb 2025 18:51:26 +0000 Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tfkUd-003MWc-16 for pgsql-hackers@lists.postgresql.org; Wed, 05 Feb 2025 18:51:25 +0000 Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 1DE90114009B; Wed, 5 Feb 2025 13:51:23 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Wed, 05 Feb 2025 13:51:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1738781483; x=1738867883; bh=u yuJJpzfqbkeEWwBgDYwzeX/r7WBPmv0SA18D9xQfU4=; b=WQhHrAHaCGCV88PJZ bBGQpfrO9IH2zV1GJgyp9bHOesW1mSj1z7SeQ6eE+bewnHkapqTfqPTw+F64GIz5 /2Ylxi/XODWq02MwMcSKLUV3y7VXUeQ0EDochK7Ua/hWIU5frTMA5+o9Ht2OAUGF bdfb0BJmrdl4kPSsH+zpn1L++Iqa39nzg0h1T6DqUshyRopsLZD4R+YtM4uwpBVM ZB8/QWHd6KsoHeIkBcH0MLVuV1dvXILAFuD0fdEL16xMPbwkleApU0qev65yGzMV QF5dghzt2SX9yYMcccOLMus68dEfJ/iracmAXBbL6VSSYS6ppCLDkZjjQa0IRFX9 wpZoQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvgedvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdej necuhfhrohhmpemllhhvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvh hhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpedvheeuffehgfeukeeufeeh hefghfeugfefudekjeevudffgeffkeegffffveegheenucffohhmrghinhepvghnthgvrh hprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrghdpnhgspg hrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepvghulhgvrhes vghulhgvrhhtohdrtghomhdprhgtphhtthhopehpghhsqhhlqdhhrggtkhgvrhhssehlih hsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Feb 2025 13:51:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1738781480; bh=Isron/fyC37XFyvfpxDi0Rq4EYlKT+T2DYoFRLH/VAk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=K2gWwlFoBbQNEjNzQTBP3yAAHuaQsIDh2T7ciqgsJfdeNSW4Qij6IxXN/ARcWfXfI voVFqfRMBKwne0npbOOp/Ltsp7KpkkFewKPddq1Yac9ApDgPzLBWbFpgnboP2VjHjN +F8LqtLQEPqWRo9ZJ734a47t5OWPJJIXC8mUlx4kd4iJ+y4zEZBJFuoUUE9QeC6dpH KWR2Zc94dZY1NDkRJIp7WO4sTBcSV9pHDW2MZr5rrxAcY61JorGlnpOipHPBdoX+Dh dLCHTQsAl/QhgbIatmHNhD6ahkCggWiGwq7AXGKT5h57DGOp7/Pmsw3Uo+z5yVAXbA 7/m/MFt36uXOQ== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id CEE7090; Wed, 5 Feb 2025 19:51:20 +0100 (CET) Date: Wed, 5 Feb 2025 19:51:20 +0100 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Euler Taveira Cc: pgsql-hackers@lists.postgresql.org Subject: Re: log_min_messages per backend type Message-ID: <202502051851.2nvzh3a6ukzc@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello Euler, On 2024-Dec-17, Euler Taveira wrote: > Sometimes you need to inspect some debug messages from autovacuum worker but > you cannot apply the same setting for backends (that could rapidly fill the log > file). This proposal aims to change log_min_messages to have different log > levels depending on which backend type the message comes from. > > The syntax was changed from enum to string and it accepts a list of elements. > > Instead of enum, it now accepts a comma-separated list of elements (string). > Each element is LOGLEVEL:BACKENDTYPE. This format seems unintuitive. I would have thought you do it the other way around, "backendtype:loglevel" ... that seems more natural because it's like assigning the 'loglevel' value to the 'backendtype' element. SET log_min_messages TO 'checkpointer:debug2, autovacuum:debug1'; I dislike the array of names in variable.c. We already have an array in launch_backend.c (child_process_kinds), plus GetBackendTypeDesc in miscinit.c. Maybe not for this patch to clean up though. I think it should be acceptable to configure one global setting with exceptions for particular backend types: log_min_messages = WARNING, autovacuum:DEBUG1 Right now I think the code only accepts the unadorned log level if there are no other items in the list. I think the proposal downthread is to use the keyword ALL for this, log_min_messages = all:WARNING, autovacuum:DEBUG1 # I don't like this but I think it's inferior, because then "all" is not really "all", and I think it would be different if I had said log_min_messages = autovacuum:DEBUG1, all:WARNING # I don't like this because it looks like the "all" entry should override the one I set for autovacuum before, which frankly would not make sense to me. So I think these two lines, log_min_messages = WARNING, autovacuum:DEBUG1 log_min_messages = autovacuum:DEBUG1, WARNING should behave identically and mean "set the level for autovacuum to DEBUG1, and to any other backend type to WARNING. Also, I think it'd be better to reject duplicates in the list. Right now it looks like the last entry for one backend type overrides prior ones. I mean log_min_messages = autovacuum:DEBUG1, autovacuum:ERROR would set autovacuum to error, but that might be mistake prone if your string is long. So implementation-wise I suggest to initialize the whole newlogminmsgs array to -1, then scan the list of entries (saving an entry without backend type as the one to use later and) setting every backend type to the number specified; if we see trying to set a value that's already different from -1, throw error. After scanning the whole log_min_messages array, we scan the newlogminmsgs and set any entries that are still -1 to the value that we saved before. The new code in variable.c should be before the /* DATESTYLE */ comment rather than at the end of the file. You still have many XXX comments. Also, postgresql.conf should list the valid values for backendtype, as well as show an example of a valid setting. Please don't use ALLCAPS backend types in the docs, this looks ugly: > + Valid BACKENDTYPE values are ARCHIVER, > + AUTOVACUUM, BACKEND, > + BGWORKER, BGWRITER, > + CHECKPOINTER, LOGGER, > + SLOTSYNCWORKER, WALRECEIVER, > + WALSENDER, WALSUMMARIZER, and > + WALWRITER. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "No necesitamos banderas No reconocemos fronteras" (Jorge González)