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