public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Fix memory leak of primary_sysid in walreceiver
2+ messages / 2 participants
[nested] [flat]
* [PATCH] Fix memory leak of primary_sysid in walreceiver
@ 2026-04-26 17:01 DaeMyung Kang <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: DaeMyung Kang @ 2026-04-26 17:01 UTC (permalink / raw)
To: [email protected]; +Cc: DaeMyung Kang <[email protected]>
Hi, Hackers,
In WalReceiverMain(), the outer streaming loop calls
walrcv_identify_system() once per iteration to verify the primary's
system identifier:
primary_sysid = walrcv_identify_system(wrconn, &primaryTLI);
...
if (strcmp(primary_sysid, standby_sysid) != 0)
ereport(ERROR, ...);
walrcv_identify_system() (libpqrcv_identify_system() in
libpqwalreceiver.c) returns a pstrdup()'d string, but the caller
never frees it. Each streaming restart therefore leaks the string.
The error path is unaffected because the surrounding memory context
is reset on ERROR.
The attached patch adds a pfree(primary_sysid) right after the
comparison.
This dates back to commit 78c8c814390 ("Refactor libpqwalreceiver",
2016), so it should be a back-patch candidate as well.
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] 0002-Fix-memory-leak-of-primary_sysid-in-walreceiver.patch (540B, 2-0002-Fix-memory-leak-of-primary_sysid-in-walreceiver.patch)
download | inline diff:
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index 23fce948967..8dbfaffaa9a 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -327,6 +327,7 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
errdetail("The primary's identifier is %s, the standby's identifier is %s.",
primary_sysid, standby_sysid)));
}
+ pfree(primary_sysid);
/*
* Confirm that the current timeline of the primary is the same or
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [PATCH] Fix memory leak of primary_sysid in walreceiver
@ 2026-04-27 00:36 Michael Paquier <[email protected]>
parent: DaeMyung Kang <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Michael Paquier @ 2026-04-27 00:36 UTC (permalink / raw)
To: DaeMyung Kang <[email protected]>; +Cc: [email protected]
On Mon, Apr 27, 2026 at 02:01:30AM +0900, DaeMyung Kang wrote:
> The attached patch adds a pfree(primary_sysid) right after the
> comparison.
My first impression was that it does not matter because I was under
the impression that this code path is only reached once, but that's
not the case: a WAL receiver could stay around waiting for
instructions before retrying a connection.
I doubt that this is worth bothering for in the back branches, as it
just means a small leak each time we switch to a new TLI repeatedly,
something that would matter mostly for a cascading standby where we
don't want to change the connection point (a SIGHUP'd primary_conninto
enforces a WAL receiver shutdown). Let's clean up on HEAD, though.
--
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:36 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 17:01 [PATCH] Fix memory leak of primary_sysid in walreceiver DaeMyung Kang <[email protected]>
2026-04-27 00:36 ` 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