public inbox for [email protected]
help / color / mirror / Atom feedFrom: Daniil Davydov <[email protected]>
To: Peter Smith <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Get rid of redundant StringInfo accumulation
Date: Mon, 30 Mar 2026 13:36:35 +0700
Message-ID: <CAJDiXgjXmU9jKKsyRCMuQu25NiRDLJch6-r7LzK1=3FFZA=sMQ@mail.gmail.com> (raw)
In-Reply-To: <CAHut+PvX8s0KBFeKOq+O1T+R0pdBGOp445QK1p6nVScnxSLFaA@mail.gmail.com>
References: <CAJDiXgi=Vcp1nh2UoZ5=7BCoR+uXoYzqMsfOfga-XxSUHjFj5Q@mail.gmail.com>
<CAHut+PvX8s0KBFeKOq+O1T+R0pdBGOp445QK1p6nVScnxSLFaA@mail.gmail.com>
Hi,
On Mon, Mar 30, 2026 at 4:52 AM Peter Smith <[email protected]> wrote:
>
> 1.
> @@ -108,6 +108,9 @@ ReportApplyConflict(EState *estate, ResultRelInfo
> *relinfo, int elevel,
> Relation localrel = relinfo->ri_RelationDesc;
> StringInfoData err_detail;
>
> + if (!message_level_is_interesting(elevel))
> + return;
> +
>
> AFAICT, this change will also cause the
> pgstat_report_subscription_conflict() to be skipped. But that call was
> not associated with the log level.
>
Thank you for looking into it!
Yeah, now the report_subscription_conflict call may be mistakenly skipped.
Since it just adds pgstat pending entry and does not depend on the log level,
I'll move this call above the log level check. I think this is OK, because
pgstat accumulation has nothing common with logging that we are trying to skip.
Please, see the updated patch.
--
Best regards,
Daniil Davydov
Attachments:
[text/x-patch] v2-0001-Get-rid-of-redundant-calculations.patch (3.5K, 2-v2-0001-Get-rid-of-redundant-calculations.patch)
download | inline diff:
From 16ce0a53e50c115c13f54ccb7539abad166048b3 Mon Sep 17 00:00:00 2001
From: Daniil Davidov <[email protected]>
Date: Mon, 30 Mar 2026 13:24:03 +0700
Subject: [PATCH v2] Get rid of redundant calculations
---
src/backend/replication/logical/conflict.c | 7 +++++--
src/backend/storage/ipc/procarray.c | 3 +++
src/backend/storage/ipc/standby.c | 3 +++
src/backend/storage/lmgr/lock.c | 2 +-
src/backend/utils/init/postinit.c | 3 ++-
5 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/backend/replication/logical/conflict.c b/src/backend/replication/logical/conflict.c
index ca71a81c7bf..7b676ce1c69 100644
--- a/src/backend/replication/logical/conflict.c
+++ b/src/backend/replication/logical/conflict.c
@@ -108,6 +108,11 @@ ReportApplyConflict(EState *estate, ResultRelInfo *relinfo, int elevel,
Relation localrel = relinfo->ri_RelationDesc;
StringInfoData err_detail;
+ pgstat_report_subscription_conflict(MySubscription->oid, type);
+
+ if (!message_level_is_interesting(elevel))
+ return;
+
initStringInfo(&err_detail);
/* Form errdetail message by combining conflicting tuples information. */
@@ -120,8 +125,6 @@ ReportApplyConflict(EState *estate, ResultRelInfo *relinfo, int elevel,
conflicttuple->ts,
&err_detail);
- pgstat_report_subscription_conflict(MySubscription->oid, type);
-
ereport(elevel,
errcode_apply_conflict(type),
errmsg("conflict detected on relation \"%s.%s\": conflict=%s",
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..7e9bfac634f 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -5267,6 +5267,9 @@ KnownAssignedXidsDisplay(int trace_level)
tail = pArray->tailKnownAssignedXids;
head = pArray->headKnownAssignedXids;
+ if (!message_level_is_interesting(trace_level))
+ return;
+
initStringInfo(&buf);
for (i = tail; i < head; i++)
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..2f2c0df7b74 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -282,6 +282,9 @@ LogRecoveryConflict(RecoveryConflictReason reason, TimestampTz wait_start,
StringInfoData buf;
int nprocs = 0;
+ if (!message_level_is_interesting(LOG))
+ return;
+
/*
* There must be no conflicting processes when the recovery conflict has
* already been resolved.
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 234643e4dd7..69dd21f178b 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -1172,7 +1172,7 @@ LockAcquireExtended(const LOCKTAG *locktag,
* logLockFailure = true and lock acquisition fails with dontWait
* = true
*/
- if (logLockFailure)
+ if (logLockFailure && message_level_is_interesting(LOG))
{
StringInfoData buf,
lock_waiters_sbuf,
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 26118661f07..1fb00faa978 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -269,7 +269,8 @@ PerformAuthentication(Port *port)
/* Capture authentication end time for logging */
conn_timing.auth_end = GetCurrentTimestamp();
- if (log_connections & LOG_CONNECTION_AUTHORIZATION)
+ if ((log_connections & LOG_CONNECTION_AUTHORIZATION) &&
+ message_level_is_interesting(LOG))
{
StringInfoData logmsg;
--
2.43.0
view thread (9+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Get rid of redundant StringInfo accumulation
In-Reply-To: <CAJDiXgjXmU9jKKsyRCMuQu25NiRDLJch6-r7LzK1=3FFZA=sMQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox