From: Chao Li <li.evan.chao@gmail.com>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_195B91FB-BC26-49CA-8580-3734E0B72E26"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Fix pg_stat_wal_receiver to show CONNECTING status
Message-Id: <EF91FF76-1E2B-4F3B-9162-290B4DC517FF@gmail.com>
Date: Tue, 19 May 2026 13:55:14 +0800
Cc: Michael Paquier <michael.paquier@gmail.com>,
 Xuneng Zhou <xunengzhou@gmail.com>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/EF91FF76-1E2B-4F3B-9162-290B4DC517FF%40gmail.com>
Precedence: bulk


--Apple-Mail=_195B91FB-BC26-49CA-8580-3734E0B72E26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

I just tested "Add WALRCV_CONNECTING state to the WAL receiver=E2=80=9D =
and found an issue.

Commit a36164e74 added the feature, and the commit message says:
```
...
the WAL receiver is ready to stream changes. This change is useful for
monitoring purposes, especially in environments with a high latency
where a connection could take some time to be established, giving some
room between the [re]start phase and the streaming activity.
```

However, I failed to see the CONNECTING status. To simulate a =
high-latency primary connection, I shut down the real primary server and =
created a fake socket server:
```
chaol@ChaodeMacBook-Air ~ % perl -MIO::Socket::INET -e '
  $s =3D IO::Socket::INET->new(
    LocalAddr =3D> "127.0.0.1",
    LocalPort =3D> 5432,
    Listen =3D> 1,
    ReuseAddr =3D> 1
  ) or die $!;
  $c =3D $s->accept;
  sleep 600;
'
```

Then pg_stat_wal_receiver only shows an empty result:
```
evantest=3D# SELECT * FROM pg_stat_wal_receiver;
 pid | status | receive_start_lsn | receive_start_tli | written_lsn | =
flushed_lsn | received_tli | last_msg_send_time | last_msg_receipt_time =
| latest_end_lsn | latest_end_time | slot_name | sender_host | =
sender_port | conninfo
=
-----+--------+-------------------+-------------------+-------------+-----=
--------+--------------+--------------------+-----------------------+-----=
-----------+-----------------+-----------+-------------+-------------+----=
------
(0 rows)
```

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.

Given that the original commit message explicitly mentions =E2=80=9Cmonito=
ring purposes=E2=80=9D, I think hiding this status during the connecting =
phase is a bug. I tried to fix it by showing only the PID and CONNECTING =
status when WalRcv->ready_to_display is false, like this:
```
evantest=3D# SELECT * FROM pg_stat_wal_receiver;
 pid  |   status   | receive_start_lsn | receive_start_tli | written_lsn =
| flushed_lsn | received_tli | last_msg_send_time | =
last_msg_receipt_time | latest_end_lsn | latest_end_time | slot_name | =
sender_host | sender_port | conninfo
=
------+------------+-------------------+-------------------+-------------+=
-------------+--------------+--------------------+-----------------------+=
----------------+-----------------+-----------+-------------+-------------=
+----------
 3256 | connecting |                   |                   |             =
|             |              |                    |                      =
 |                |                 |           |             |          =
   |
(1 row)
```

See the attached patch for details.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/


--Apple-Mail=_195B91FB-BC26-49CA-8580-3734E0B72E26
Content-Disposition: attachment;
	filename=v1-0001-Fix-pg_stat_wal_receiver-to-show-CONNECTING-statu.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="v1-0001-Fix-pg_stat_wal_receiver-to-show-CONNECTING-statu.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=20817d3c881dd6d3912635c89d7aa24407576a85d8=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20"Chao=20Li=20(Evan)"=20<lic@highgo.com>=0A=
Date:=20Tue,=2019=20May=202026=2013:32:15=20+0800=0ASubject:=20[PATCH=20=
v1]=20Fix=20pg_stat_wal_receiver=20to=20show=20CONNECTING=20status=0A=0A=
Commit=20a36164e7465=20added=20a=20CONNECTING=20status=20for=20the=20WAL=20=
receiver,=20but=0Apg_stat_wal_receiver=20still=20returned=20no=20row=20=
while=20ready_to_display=20was=0Afalse.=20=20That=20made=20the=20new=20=
status=20invisible=20during=20the=20connection=20setup=0Aphase.=0A=0A=
Allow=20pg_stat_wal_receiver=20to=20show=20the=20WAL=20receiver=20PID=20=
and=20status=20once=0Athey=20have=20been=20advertised,=20even=20before=20=
connection=20details=20are=20ready=20to=0Adisplay.=20=20Keep=20the=20=
remaining=20fields=20NULL=20until=20conninfo=20has=20been=0Aobfuscated.=0A=
=0AAuthor:=20Chao=20Li=20<lic@highgo.com>=0A---=0A=20=
src/backend/replication/walreceiver.c=20|=2036=20=
+++++++++++++++++----------=0A=201=20file=20changed,=2023=20=
insertions(+),=2013=20deletions(-)=0A=0Adiff=20--git=20=
a/src/backend/replication/walreceiver.c=20=
b/src/backend/replication/walreceiver.c=0Aindex=20=
07eac07b9ce..78d948adc49=20100644=0A---=20=
a/src/backend/replication/walreceiver.c=0A+++=20=
b/src/backend/replication/walreceiver.c=0A@@=20-1474,21=20+1474,10=20@@=20=
pg_stat_get_wal_receiver(PG_FUNCTION_ARGS)=0A=20=09strlcpy(conninfo,=20=
WalRcv->conninfo,=20sizeof(conninfo));=0A=20=09=
SpinLockRelease(&WalRcv->mutex);=0A=20=0A-=09/*=0A-=09=20*=20No=20WAL=20=
receiver=20(or=20not=20ready=20yet),=20just=20return=20a=20tuple=20with=20=
NULL=0A-=09=20*=20values=0A-=09=20*/=0A-=09if=20(pid=20=3D=3D=200=20||=20=
!ready_to_display)=0A+=09/*=20No=20WAL=20receiver,=20just=20return=20a=20=
tuple=20with=20NULL=20values=20*/=0A+=09if=20(pid=20=3D=3D=200)=0A=20=09=09=
PG_RETURN_NULL();=0A=20=0A-=09/*=0A-=09=20*=20Read=20"writtenUpto"=20=
without=20holding=20a=20spinlock.=20=20Note=20that=20it=20may=20not=20be=0A=
-=09=20*=20consistent=20with=20the=20other=20shared=20variables=20of=20=
the=20WAL=20receiver=0A-=09=20*=20protected=20by=20a=20spinlock,=20but=20=
this=20should=20not=20be=20used=20for=20data=20integrity=0A-=09=20*=20=
checks.=0A-=09=20*/=0A-=09written_lsn=20=3D=20=
pg_atomic_read_u64(&WalRcv->writtenUpto);=0A-=0A=20=09/*=20determine=20=
result=20type=20*/=0A=20=09if=20(get_call_result_type(fcinfo,=20NULL,=20=
&tupdesc)=20!=3D=20TYPEFUNC_COMPOSITE)=0A=20=09=09elog(ERROR,=20"return=20=
type=20must=20be=20a=20row=20type");=0A@@=20-1512,6=20+1501,27=20@@=20=
pg_stat_get_wal_receiver(PG_FUNCTION_ARGS)=0A=20=09{=0A=20=09=09=
values[1]=20=3D=20CStringGetTextDatum(WalRcvGetStateString(state));=0A=20=
=0A+=09=09/*=0A+=09=09=20*=20The=20WAL=20receiver=20advertises=20its=20=
PID=20and=20state=20before=20connection=0A+=09=09=20*=20details=20are=20=
safe=20to=20display.=20=20Show=20the=20state,=20but=20keep=20all=20other=0A=
+=09=09=20*=20details=20hidden=20until=20conninfo=20has=20been=20=
obfuscated.=0A+=09=09=20*/=0A+=09=09if=20(!ready_to_display)=0A+=09=09{=0A=
+=09=09=09memset(&nulls[2],=20true,=20sizeof(bool)=20*=20(tupdesc->natts=20=
-=202));=0A+=0A+=09=09=09=
PG_RETURN_DATUM(HeapTupleGetDatum(heap_form_tuple(tupdesc,=20values,=0A+=09=
=09=09=09=09=09=09=09=09=09=09=09=09=09=09=20=20nulls)));=0A+=09=09}=0A+=0A=
+=09=09/*=0A+=09=09=20*=20Read=20"writtenUpto"=20without=20holding=20a=20=
spinlock.=20=20Note=20that=20it=20may=0A+=09=09=20*=20not=20be=20=
consistent=20with=20the=20other=20shared=20variables=20of=20the=20WAL=0A=
+=09=09=20*=20receiver=20protected=20by=20a=20spinlock,=20but=20this=20=
should=20not=20be=20used=20for=0A+=09=09=20*=20data=20integrity=20=
checks.=0A+=09=09=20*/=0A+=09=09written_lsn=20=3D=20=
pg_atomic_read_u64(&WalRcv->writtenUpto);=0A+=0A=20=09=09if=20=
(!XLogRecPtrIsValid(receive_start_lsn))=0A=20=09=09=09nulls[2]=20=3D=20=
true;=0A=20=09=09else=0A--=20=0A2.50.1=20(Apple=20Git-155)=0A=0A=

--Apple-Mail=_195B91FB-BC26-49CA-8580-3734E0B72E26--