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.96) (envelope-from ) id 1w4fix-002Qyz-1w for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Mar 2026 13:53:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w4fiw-000M1H-0G for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Mar 2026 13:53:42 +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.96) (envelope-from ) id 1w4fiv-000M18-2Z for pgsql-hackers@lists.postgresql.org; Mon, 23 Mar 2026 13:53:42 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w4fiu-00000000dGO-2A7S for pgsql-hackers@lists.postgresql.org; Mon, 23 Mar 2026 13:53:41 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-40f1a1f77a6so2977695fac.2 for ; Mon, 23 Mar 2026 06:53:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774274020; cv=none; d=google.com; s=arc-20240605; b=O7Z2W2+CaoJS1ZGYniy5aWOeFZvxZFtb5ByVKq4xmMkDJ9iyKqFUhcBts3itZlAEOa KR2hQ3dGhwahPrKn6FtcZHW/gGzbw/yxyKuU6WTVj8PpTVcqU5vMSrDcrT4O3DgbXkME xFtmliO3igJCIRe/50KjoyLStWk1fbFi0fYDbXTAP961XJ/ay4IKXInKoQ5f5H5SLo5m fpUOzlG/xtdMaP3YCv8JuG94iRhjUJbMgkf1U8ijlh2rd6XEdR7HrFUEvlpyfwSAdDRp V94nCG/ZBQxG6zV47Q9zm+p5SixQ3FETfip+FXZBJT4D5bxSb2eI0ll31sGqDOucWGV7 yhoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=VHntA8UUAVbZvCAJMxdFTZAvB32F120LjQ3Wrz4xbm0=; fh=x4xgi4tdDukVB0fBuAIe3vORvD36rbbTBlhrrGN8QbM=; b=U4bzRaNYKEG/m4OLDaez2WqqBrbmWinhMu6C/V2TL+dPnjA3ZxkquGZNvojD2bJ9z/ jUN7NAkfIDWkT9revSRCQidjfZpICWIHLimraITbO92CrqbTXxxoYM6oopRb6/caGe/Z VHpvQEuq/wjMgFnrGVahoqSpRaf+sEss2YknSN3zwv9wpl51e/JTGe4CX1XzzXsx6yrT L4rju83ATovvWFE8y9LqTR07aJIYfGUhCnbU89LyfKdbMhNPIdNaRS1zhGCfja2WCFMu NWrZ3WLhgkWCXSe7ecSDQqUAPR2gfBxf/6AsXjiqc09Ed9/Y4CwL5/9P1XKl906XFIUs KSAw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774274020; x=1774878820; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VHntA8UUAVbZvCAJMxdFTZAvB32F120LjQ3Wrz4xbm0=; b=YjVdOXnWspk8GqFKkU+NsU29+gHCyZCS8HW5j43R70LiLN0ZhfrojS/SMUiGi/siaf 3ow9m76TjdXPY2+EcQ1CKf0SCi0aBLNEIozGqE6pl5e7TwZAXhXyzgz1uFnlNuSk2Oir 2aXX+Uj3grPhE4CVr4EDOuA5Ar2O/ZGcMfIzObksW5edSYKmqJitP0mG7qb6DcZKEjew /+L9D9JeUFsP/6zKXwoxcl9XEKnjib1rReqo2kXpRwg04La+gTSAeLXbMcrSDX9yqZ2U L5P8FTjbfZR1mz0JpaHE5bz+YNup3cG+BAZwCZ30c8qRWmk/fPI9UTarIAH6ECqAN1NP cX6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774274020; x=1774878820; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=VHntA8UUAVbZvCAJMxdFTZAvB32F120LjQ3Wrz4xbm0=; b=q0VIrjdILw6LMU9hLnJoJXpjkm9zvafMBFtUCEcEmO6XXb66ueOzr2/K4kq0JLUvfJ 2A0brDrCkT/lEHmW+8Jfb6J1TaOFKZ8eU74SKFZagZTpWtuScBVqRFxb4FkV4i4iFlmj letAlJyY/+/xceEi1vNRyDjXEJZbWnIFX5aMGu16Obl6OSjoRvbmp5XmEwdWX7x2JKvA l5kOOISpfZf4oTesZ3JeB1ztGGK9nnAw8NtAGMadeQQEdTi/EaYxJQP1urtYBsLOki7n wLt54JXUTaH3G7L2nN04LGd0Q8oX6stAvWyTWr/iSSpyFNLovZIDhOyiNcC2AMG1DzmG 3CyQ== X-Gm-Message-State: AOJu0YwxeNflslRbCVEObTiFI8InxXxWCtc5PtcKWfcePR88F8YZpsIm 6s4UMYseFUVfIKSL0SW/lHgR1R2dkbXks1uN02XZ/bkI/H3wbwCRXOitvFowiH68+LudZRBr8K2 XI9HcLvVZUqFRGcFgIOnHyUCeaB1amo0= X-Gm-Gg: ATEYQzwyEbPWEyQO3j9DfERgLvOM0IQZofPWTyAUqb76wL+byMqYo+3UrQFtY7Sk1EY AB4NpP/JK9yEqW21mBPbcvKGWD8ZYHhraQ5cJTBtac2A4/f4pfHkC2C/bAXcMaaRBYRd1MoPI5z UG/YGdp45eE1EhvJmmXqDQB06uyzmulBrEkhyP6FkSmem5iTn9HYa9LLZQASTQC5+woR1whxaP8 agRKMYhaVwi8kJSCblK+KiwguHk9blFDWZQxdBOAQgjRNmOCzAHBsy1+IYr84be3GcoB5qXC53O kEbkk9S/nrDRZQb+E34tT0i7wppN/f0Movr+mnM= X-Received: by 2002:a05:6820:190b:b0:67c:1fb8:4cb1 with SMTP id 006d021491bc7-67c22ef51a9mr8287364eaf.8.1774274019654; Mon, 23 Mar 2026 06:53:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bharath Rupireddy Date: Mon, 23 Mar 2026 06:53:28 -0700 X-Gm-Features: AaiRm537L_pW4bQGApyrM-EPO5139zWQ1WffQYoVyolT216oIzp26uULOuH52-k Message-ID: Subject: Re: Reduce log level of some logical decoding messages to DEBUG1 To: Fujii Masao Cc: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Mon, Mar 23, 2026 at 1:23=E2=80=AFAM Fujii Masao = wrote: > > In logical decoding, messages like the following are currently logged at > LOG level: > > LOG: starting logical decoding for slot "myslot" > DETAIL: Streaming transactions committing after 0/030872C0, > reading WAL from 0/03087288. > STATEMENT: ... > LOG: logical decoding found consistent point at 0/03087288 > DETAIL: There are no running transactions. > STATEMENT: ... > > These can be useful for debugging, but DBAs are typically not interested = in > them. They can also be emitted frequently, for example, on each call to > functions like pg_logical_slot_peek_binary_changes() or > pg_replication_slot_advance() etc. When such functions are called repeate= dly, > the logs can quickly become noisy. I understand the chattiness of these when the decoding is done using functions. But they seem to be useful when decoding using walsender and replication connection. Also, it looks to me that the errdetail describing various cases like when there are no running transactions, when logical decoding will begin using saved snapshot, etc., is helpful. > The slotsync worker can also generate these messages periodically. Due to > the issue discussed at [1], this can currently happen as often as every 2= 00ms > (which should be fixed separately). Even without that issue, these messag= es > would be still emitted regularly. > > Given that these are mostly developer-oriented messages, logging them at > LOG level seems too verbose. I'm proposing to reduce their level to DEBUG= 1. > A patch is attached. > > Alternatively, if we want to keep them at LOG by default, we could introd= uce > a GUC like trace_logical_decoding_messages, similar to > the old trace_recovery_messages, to control their verbosity independently > of log_min_messages. > > Thought? 1 for another GUC IMHO. How about we find if the logical decoding is being done using walsender (a boolean like isDecodingUsingWalSender, default being false, set to true when in walsender) and emit them at LOG level when set to true. Would something like this work? --=20 Bharath Rupireddy Amazon Web Services: https://aws.amazon.com