public inbox for [email protected]
help / color / mirror / Atom feedFrom: Daniil Davydov <[email protected]>
To: Postgres hackers <[email protected]>
Subject: Get rid of redundant StringInfo accumulation
Date: Sun, 29 Mar 2026 19:26:11 +0700
Message-ID: <CAJDiXgi=Vcp1nh2UoZ5=7BCoR+uXoYzqMsfOfga-XxSUHjFj5Q@mail.gmail.com> (raw)
Hi,
I have noticed that there are several places in the code where we are
creating StringInfo in order to log its content. But this work may be wasted
if the specified log level is not interesting both for client and server.
I.e. now we can allocate memory for StringInfo which will never be displayed.
I think that at first we should check whether log level is interesting and
only then start creating the StringInfo.
Please, see the attached patch that fixes it. I hope I have found all the
places where it would be appropriate.
--
Best regards,
Daniil Davydov
Attachments:
[text/x-patch] v1-0001-Get-rid-of-redundant-calculations.patch (3.1K, 2-v1-0001-Get-rid-of-redundant-calculations.patch)
download | inline diff:
From cd1a85bfd71dc875a9f7a166c0fb2f0604a5a1ce Mon Sep 17 00:00:00 2001
From: Daniil Davidov <[email protected]>
Date: Sun, 29 Mar 2026 19:17:11 +0700
Subject: [PATCH v1] Get rid of redundant calculations
---
src/backend/replication/logical/conflict.c | 3 +++
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, 12 insertions(+), 2 deletions(-)
diff --git a/src/backend/replication/logical/conflict.c b/src/backend/replication/logical/conflict.c
index ca71a81c7bf..202989eada3 100644
--- a/src/backend/replication/logical/conflict.c
+++ b/src/backend/replication/logical/conflict.c
@@ -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;
+
initStringInfo(&err_detail);
/* Form errdetail message by combining conflicting tuples information. */
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..7d325b21324 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]
Subject: Re: Get rid of redundant StringInfo accumulation
In-Reply-To: <CAJDiXgi=Vcp1nh2UoZ5=7BCoR+uXoYzqMsfOfga-XxSUHjFj5Q@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