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
if (sender_host)
pfree(sender_host);
+ /* Initialize buffers for processing messages */
+ initStringInfo(&reply_message);
+
first_stream = true;
for (;;)
{
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
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();