From: Chao Li <li.evan.chao@gmail.com>
Message-Id: <1B695040-F544-447C-A6A8-C8BFF7F799D1@gmail.com>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_85D81BDF-5576-421C-B45D-28217D850339"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: Fix pg_stat_wal_receiver to show CONNECTING status
Date: Thu, 21 May 2026 07:06:33 +0800
In-Reply-To: <ag4dCGAPBc5VFhCi@paquier.xyz>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Michael Paquier <michael.paquier@gmail.com>,
 Xuneng Zhou <xunengzhou@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
References: <EF91FF76-1E2B-4F3B-9162-290B4DC517FF@gmail.com>
 <agxr29Hsz7FjxzlN@paquier.xyz>
 <1F153E64-B791-42FA-A60A-64813B20B81E@gmail.com>
 <ag00OeH1sbt5ie_6@paquier.xyz>
 <75CDE990-29D5-4D5C-BFE1-3840F19C0163@gmail.com>
 <ag4dCGAPBc5VFhCi@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/1B695040-F544-447C-A6A8-C8BFF7F799D1%40gmail.com>
Precedence: bulk


--Apple-Mail=_85D81BDF-5576-421C-B45D-28217D850339
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 21, 2026, at 04:43, Michael Paquier <michael@paquier.xyz> =
wrote:
>=20
> On Wed, May 20, 2026 at 03:53:38PM +0800, Chao Li wrote:
>> With v2, slot_name, sender_host, sender_port, and conninfo are
>> already left NULL while the receiver is in CONNECTING state. I feel
>> we don't have to show the timestamp fields either. Since the columns
>> are named last_msg_send_time and last_msg_receipt_time, users may
>> naturally interpret them as the last time a message was sent to or
>> received from
>> the primary. If we show the standby server start time in those
>> columns, I am afraid that could be confusing.
>>=20
>> But I think it might be useful to show the *_lsn and *_tli values in
>> CONNECTING state if they are available.
>=20
> The original reason why ready_to_display has been introduced is this
> one, where we wanted to have a strict control over the connection
> information across multiple calls of pg_stat_get_wal_receiver():
> =
https://www.postgresql.org/message-id/CAB7nPqQNbHQ7F7wDD_2qvGA_FUW-Leds9HQ=
NM6kJnto7RFNhUg@mail.gmail.com
>=20
> With v2, ready_to_display is still able to do the job it is defined
> for.  This does not need to apply on the time fields, so IMO showing
> them to the values they are initialized is not a big deal, and they
> can actually be useful to know even in the early stage of connection
> as they reveal the state of the code. =20
>=20
> Note also that the time values could still show up based on their
> initial values at the early connection stage, even after completing
> walrcv_connect() and after ready_to_display is switched to true, so
> it's not like these values are that confusing: we just expose them a
> bit more at an earlier stage of the connection attempt process.  As a
> whole v2 is fine, and addresses your issue.
> --
> Michael

Thanks for the detailed explanation.

Now I see that, based on the original discussion you pointed out, as =
long as v2 clears conninfo before setting ready_to_display to true, it =
is okay to do that earlier while the state is still CONNECTING. On that =
point, I=E2=80=99m good with v2.

I=E2=80=99m still not fully convinced about displaying the *_time =
fields, but I don=E2=80=99t have a stronger argument either, so I=E2=80=99=
m fine with that. Maybe we can add a brief description in the doc like =
the attached diff?

Overall, v2 looks good to me now.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/


--Apple-Mail=_85D81BDF-5576-421C-B45D-28217D850339
Content-Disposition: attachment;
	filename=nocfbot_monitoring.sgml.diff
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="nocfbot_monitoring.sgml.diff"
Content-Transfer-Encoding: 7bit

diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 08d5b824552..d2c8d547a91 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -1743,6 +1743,12 @@ description | Waiting for a newly initialized WAL file to reach durable storage
    connected server.
   </para>
 
+  <para>
+   When the WAL receiver is in <literal>connecting</literal> state, the time
+   fields in this view may reflect their initial values rather than values
+   received from the WAL sender.
+  </para>
+
   <table id="pg-stat-wal-receiver-view" xreflabel="pg_stat_wal_receiver">
    <title><structname>pg_stat_wal_receiver</structname> View</title>
    <tgroup cols="1">

--Apple-Mail=_85D81BDF-5576-421C-B45D-28217D850339--