> On May 21, 2026, at 20:08, Michael Paquier <michael@paquier.xyz> 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/
