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
signature.asc
Description: PGP signature
