> On May 21, 2026, at 20:08, Michael Paquier <[email protected]> wrote: > > 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
Sorry for missing the attachments. Please take a look first. It’s late here, I can spend more time tomorrow. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
nocfbot_test.diff
Description: Binary data
nocfbot_walreceiverfuncs.c.diff
Description: Binary data
