Fix some memory leaks in the WAL receiver

These are old leaks, that can pile up if a WAL receiver stays alive,
waiting for new WAL data after the sender has switched to a new
timeline.

While this is technically a bug, the impact is minimal and would only
become noticeable if the WAL sender handles a lot of timeline switches,
so no backpatch is done.  Note that in most cases, primary_conninfo
would be updated in a standby to point to a new sender, meaning a
restart of the WAL receiver.  Let's be clean on HEAD, though.

Author: DaeMyung Kang <charsyam@gmail.com>
Discussion: https://postgr.es/m/20260426170100.847923-1-charsyam@gmail.com
Discussion: https://postgr.es/m/20260426170219.849330-1-charsyam@gmail.com
This commit is contained in:
Michael Paquier 2026-04-27 10:32:45 +09:00
parent f9c638054c
commit b801d5eef1

View file

@ -302,6 +302,9 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
if (sender_host)
pfree(sender_host);
/* Initialize buffers for processing messages */
initStringInfo(&reply_message);
first_stream = true;
for (;;)
{
@ -325,6 +328,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
@ -405,9 +409,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();