public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Fix memory leak of reply_message in walreceiver
2+ messages / 2 participants
[nested] [flat]
* [PATCH] Fix memory leak of reply_message in walreceiver
@ 2026-04-26 16:59 DaeMyung Kang <[email protected]>
2026-04-27 00:46 ` Re: [PATCH] Fix memory leak of reply_message in walreceiver Michael Paquier <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: DaeMyung Kang @ 2026-04-26 16:59 UTC (permalink / raw)
To: [email protected]; +Cc: DaeMyung Kang <[email protected]>
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();
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [PATCH] Fix memory leak of reply_message in walreceiver
2026-04-26 16:59 [PATCH] Fix memory leak of reply_message in walreceiver DaeMyung Kang <[email protected]>
@ 2026-04-27 00:46 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Michael Paquier @ 2026-04-27 00:46 UTC (permalink / raw)
To: DaeMyung Kang <[email protected]>; +Cc: [email protected]
On Mon, Apr 27, 2026 at 01:59:09AM +0900, DaeMyung Kang wrote:
> 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.
This is a problem similar to [1], and I'd agree about cleaning that up
properly.
> 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.
This is minor, so I don't really see a point in back-patching. Same
reason as the other thread.
I'll go merge that together.
[1]: https://www.postgresql.org/message-id/[email protected]
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-04-27 00:46 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-26 16:59 [PATCH] Fix memory leak of reply_message in walreceiver DaeMyung Kang <[email protected]>
2026-04-27 00:46 ` Michael Paquier <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox