Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 19 May 2026 22:55:39 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Chao Li <li.evan.chao@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Michael Paquier <michael.paquier@gmail.com>,
	Xuneng Zhou <xunengzhou@gmail.com>
Subject: Re: Fix pg_stat_wal_receiver to show CONNECTING status
Message-ID: <agxr29Hsz7FjxzlN@paquier.xyz>
References: <EF91FF76-1E2B-4F3B-9162-290B4DC517FF@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="0hPT/xDoEPF3U+Iq"
Content-Disposition: inline
In-Reply-To: <EF91FF76-1E2B-4F3B-9162-290B4DC517FF@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/agxr29Hsz7FjxzlN%40paquier.xyz>
Precedence: bulk


--0hPT/xDoEPF3U+Iq
Content-Type: multipart/mixed; boundary="e8mCT7dYzTZ0SOZf"
Content-Disposition: inline


--e8mCT7dYzTZ0SOZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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 =3D=3D 0 || !ready_to_display)
+	/* No WAL receiver, just return a tuple with NULL values */
+	if (pid =3D=3D 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

--e8mCT7dYzTZ0SOZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename=v2-0001-Improve-pg_stat_wal_receiver-for-CONNECTING-statu.patch
Content-Transfer-Encoding: quoted-printable

=46rom 3c381a90b1270fdd3f1b01e8eefb85f1ac4af3d8 Mon Sep 17 00:00:00 2001
=46rom: Michael Paquier <michael@paquier.xyz>
Date: Tue, 19 May 2026 22:52:38 +0900
Subject: [PATCH v2] Improve pg_stat_wal_receiver for CONNECTING status

Commit a36164e7465 added a CONNECTING status for the WAL receiver, but
pg_stat_wal_receiver returned no information while the connection to the
primary was attempted, limiting the usability of the feature in
high-latency environments where the connection attempt to the primary
could take time.

This commit improves the report of the status by splitting the way the
shared memory state of the WAL receiver is filled before and after the
connection to the primary is attempted:
- Before the attempt, reset all the connection fields, switch
ready_to_display to true.
- After the attempt, fill in the connection fields.

This change means two spinlock acquisitions instead of one, but at least
monitoring tools can know about the connection attempt before its
completion, enlarging the usability of the feature.

Reported-by: Chao Li <li.evan.chao@gmail.com>
Author: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/XXX
---
 src/backend/replication/walreceiver.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replicatio=
n/walreceiver.c
index 07eac07b9ce4..d19317703c1f 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -267,6 +267,20 @@ WalReceiverMain(const void *startup_data, size_t start=
up_data_len)
 	/* Unblock signals (they were blocked when the postmaster forked us) */
 	sigprocmask(SIG_SETMASK, &UnBlockSig, NULL);
=20
+	/*
+	 * Switch the WAL receiver state as ready for display before doing a
+	 * connection attempt, so as its connecting state is visible before
+	 * attempting to contact the primary server.  Note that this resets the
+	 * original conninfo, sender_port and sender_host, for security.  These
+	 * fields are filled once the connection is fully established.
+	 */
+	SpinLockAcquire(&walrcv->mutex);
+	memset(walrcv->conninfo, 0, MAXCONNINFO);
+	memset(walrcv->sender_host, 0, NI_MAXHOST);
+	walrcv->sender_port =3D 0;
+	walrcv->ready_to_display =3D true;
+	SpinLockRelease(&walrcv->mutex);
+
 	/* Establish the connection to the primary for XLOG streaming */
 	appname =3D cluster_name[0] ? cluster_name : "walreceiver";
 	wrconn =3D walrcv_connect(conninfo, true, false, false, appname, &err);
@@ -277,23 +291,17 @@ WalReceiverMain(const void *startup_data, size_t star=
tup_data_len)
 						appname, err)));
=20
 	/*
-	 * Save user-visible connection string.  This clobbers the original
-	 * conninfo, for security. Also save host and port of the sender server
-	 * this walreceiver is connected to.
+	 * Save user-visible connection string, now that the connection has been
+	 * achieved.
 	 */
 	tmp_conninfo =3D walrcv_get_conninfo(wrconn);
 	walrcv_get_senderinfo(wrconn, &sender_host, &sender_port);
 	SpinLockAcquire(&walrcv->mutex);
-	memset(walrcv->conninfo, 0, MAXCONNINFO);
 	if (tmp_conninfo)
 		strlcpy(walrcv->conninfo, tmp_conninfo, MAXCONNINFO);
-
-	memset(walrcv->sender_host, 0, NI_MAXHOST);
 	if (sender_host)
 		strlcpy(walrcv->sender_host, sender_host, NI_MAXHOST);
-
 	walrcv->sender_port =3D sender_port;
-	walrcv->ready_to_display =3D true;
 	SpinLockRelease(&walrcv->mutex);
=20
 	if (tmp_conninfo)
--=20
2.54.0


--e8mCT7dYzTZ0SOZf--

--0hPT/xDoEPF3U+Iq
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmoMa9sACgkQnvQgOdby
QH3mAA//Rpm1obRgv/H4dC0UN4lXCiAoGKkTKD14r9hlrIEUPjWgdws5kUMjHh/Z
zyknBGNj9qU/rSh0jZ1p392VFJJaDtCU1xgsxy/xCg0iJucBD575yYku+3U1p4Ps
EdB9ANGbZDbkphc8EPM1qPpfrEc3E8UjJ4xdm2gAEhY7QKUS5PDsYsf9R6KzAKFI
amkEU/Xvu38+IdAYkn9lLuE6F/DoHbD2QroOkcm21Q/q6dzE2D2/21DzhVQXHxHT
IKWjGgLiNTdF+6/GfkRBDrnpWhPeDNb4I5eGtNRQ6JkoyNDU4u34TAkW1LCOGT2Q
xLMlyTa2izvpRkwTXtFivmJRUTrqvmLp7JA7lG+RNzaAtSJuSvnmM6RvL/VUmXR+
A5w/eBHQKDzULv1jrFc8NiRyirAnfAKQZX2GL9t77BJazPfODX7zuyd49jJcmcKq
BmM67odaTaLIaysnTu3rm1+nORhnQziMlsuuqtuZgARMi9g1YlZJiTqwgMOfxyfl
1Y7kQOv7PJdfhqLK81Z3tP0nW96QDnV1IPDEPcRD/TTg5BuTa4MgK3xEonED5OiO
pJBCwC5hVvtAcaDpdmFpYrtDOXqKi3vIBm+ekPMmX76pL6qfEAOcui4xh8l/cowg
Z8BMDGkqr8pVRgYqFUfL0l/V9+ikcl20RFyrVukryEA9yu25BGE=
=87db
-----END PGP SIGNATURE-----

--0hPT/xDoEPF3U+Iq--