Thread

  1. Re: Fix pg_stat_wal_receiver to show CONNECTING status

    Chao Li <li.evan.chao@gmail.com> — 2026-05-21T12:29:35Z

    
    > 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/