On Thu, May 21, 2026 at 03:20:13PM +0800, Chao Li wrote:
> I spent more time here, and found that it is still possible to leak
> conninfo in the WAL receiver reuse path:
>
> * WalRcvWaitForStartPosition() sets the state to WALRCV_WAITING.
> * Then RequestXLogStreaming() copies raw conninfo into
> * walrcv->conninfo and sets the state to WALRCV_RESTARTING.
> * WalRcvWaitForStartPosition() then moves the state to
> * WALRCV_CONNECTING, but this path does not clear walrcv->conninfo
> * again.
>
> The attached nocfbot_test.diff demonstrates the leak.
File is missing, but I get it. This is a legit bug from what I can
see, that also affects all the stable branches, not only HEAD.
> Initially I thought we could also set ready_to_display to false when
> setting the state to WALRCV_WAITING in WalRcvWaitForStartPosition(),
> and set it back to true when switching back to
> WALRCV_CONNECTING. However, that would make the WALRCV_WAITING and
> WALRCV_RESTARTING states invisible in pg_stat_wal_receiver.
Nah, we should not do that. We want to track the waiting and
restarting states in the view.
> I ended up with a solution that copies the primary connection info
> to walrcv->conninfo only when RequestXLogStreaming() is switching to
> WALRCV_STARTING. In the WALRCV_WAITING reuse path, the WAL receiver
> keeps using the existing wrconn, so it does not need raw conninfo to
> be copied into shared memory again. See the attached
> nocfbot_walreceiverfuncs.c.diff.
Ah, yeah. This solution to this problem makes sense. We should not
clobber conninfo either in this case, or we'd lose the
user-displayable string returned by walrcv_get_conninfo() (conninfo
cannot be NULL based on the in-core callers of RequestXLogStreaming()
AFAIK, but who knows for things out there). As mentioned above, this
is a different issue than the visibility of the connection information
while we are connecting, and it should be backpatched. Would you like
to send a patch?
--
Michael
