Re: Fix pg_stat_wal_receiver to show CONNECTING status

On Tue, May 19, 2026 at 01:55:14PM +0800, Chao Li wrote:
> I also tried restarting the standby server, and the result was the same.
> 
> The problem is that pg_stat_wal_receiver is gated by
> WalRcv->ready_to_display, and when the status is CONNECTING,
> WalRcv->ready_to_display is false.

Initially, I was thinking that the walrcv_connect() delay would not be
that important to track in this context, but you are right that this
stands for improvement before the release.

@@ -1474,21 +1474,10 @@ pg_stat_get_wal_receiver(PG_FUNCTION_ARGS)
-	if (pid == 0 || !ready_to_display)
+	/* No WAL receiver, just return a tuple with NULL values */
+	if (pid == 0)
 		PG_RETURN_NULL();

This suggestion is making the SQL function call feebler, IMO,
impacting the readability around ready_to_display that we want to act
as a gate to the data provided in the view.  This flag is important to
check at an early state of the function call, and I don't really want
to change that.  A better thing to do would be to split into two steps
how the WAL receiver data is filled between the walrcv_connect() call:
1) Before the call, reset all the connection-related fields because
they are not relevant before the connection to the remote is
completed, set ready_for_display to true to make the connecting state
visible in the view.   The connection information does not matter
anyway here: we cannot be sure which point we are connected to until
the connection is fully established.
2) After the call, fill in the connection-related fields.

This means taking twice the WAL receiver spinlock instead of once,
which is not going to matter in practice as the latency of the
connection attempt is much larger than that.

What do you think about the attached, then?
--
Michael