public inbox for [email protected]  

help / color / mirror / Atom feed

From: DaeMyung Kang <[email protected]>
To: [email protected]
Cc: DaeMyung Kang <[email protected]>
Subject: [PATCH] Fix memory leak of reply_message in walreceiver
Date: Mon, 27 Apr 2026 01:59:09 +0900
Message-ID: <[email protected]> (raw)

Hi, Hackers,

  While reading walreceiver.c, I noticed that the static StringInfoData
  reply_message gets initialized inside the outer streaming loop in
  WalReceiverMain(), specifically right after walrcv_startstreaming()
  succeeds:

      /* Initialize LogstreamResult and buffers for processing messages */
      LogstreamResult.Write = LogstreamResult.Flush = GetXLogReplayRecPtr(NULL);
      initStringInfo(&reply_message);

  initStringInfo() unconditionally allocates a fresh ~1KB buffer with
  palloc() and overwrites the existing data pointer without freeing the
  previous one. So every time the walreceiver re-enters the streaming
  path -- e.g., after a timeline switch, end-of-WAL, or any other
  condition that drives the outer for(;;) loop to iterate -- the prior
  buffer is leaked. The leak is bounded per streaming restart but
  accumulates over the lifetime of a long-running standby that
  restarts streaming often.

  Subsequent uses of reply_message already call resetStringInfo() to
  reuse the buffer, so a single one-time initialization before the
  outer loop is sufficient. The attached patch moves the call up and
  adjusts the comment accordingly.

  This appears to date back to commit add6c3179a4 ("Make the streaming
  replication protocol messages architecture-independent.", 2012), so
  the fix is likely a candidate for back-patching to all supported
  branches.

  No new tests are added; the fix only releases resources and does not
  change observable behavior. `make check` and the streaming replication
  TAP test (src/test/recovery/t/001_stream_rep.pl) pass with the patch
  applied.

  Patch attached.

  Regards,
  DaeMyung Kang




Attachments:

  [text/x-patch] 0001-Fix-memory-leak-of-reply_message-in-walreceiver.patch (916B, 2-0001-Fix-memory-leak-of-reply_message-in-walreceiver.patch)
  download | inline diff:
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index 8185412a810..23fce948967 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -302,6 +302,8 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 	if (sender_host)
 		pfree(sender_host);
 
+	initStringInfo(&reply_message);
+
 	first_stream = true;
 	for (;;)
 	{
@@ -405,9 +407,8 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 				walrcv->walRcvState = WALRCV_STREAMING;
 			SpinLockRelease(&walrcv->mutex);
 
-			/* Initialize LogstreamResult and buffers for processing messages */
+			/* Initialize LogstreamResult for processing messages */
 			LogstreamResult.Write = LogstreamResult.Flush = GetXLogReplayRecPtr(NULL);
-			initStringInfo(&reply_message);
 
 			/* Initialize nap wakeup times. */
 			now = GetCurrentTimestamp();

view thread (2+ 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: [PATCH] Fix memory leak of reply_message in walreceiver
  In-Reply-To: <[email protected]>

* 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