| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
| Subject: | Fix pg_stat_wal_receiver to show CONNECTING status |
| Date: | 2026-05-19 05:55:14 |
| Message-ID: | EF91FF76-1E2B-4F3B-9162-290B4DC517FF@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I just tested "Add WALRCV_CONNECTING state to the WAL receiver” 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(at)ChaodeMacBook-Air ~ % perl -MIO::Socket::INET -e '
$s = IO::Socket::INET->new(
LocalAddr => "127.0.0.1",
LocalPort => 5432,
Listen => 1,
ReuseAddr => 1
) or die $!;
$c = $s->accept;
sleep 600;
'
```
Then pg_stat_wal_receiver only shows an empty result:
```
evantest=# 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 “monitoring purposes”, 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=# 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/
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-pg_stat_wal_receiver-to-show-CONNECTING-statu.patch | application/octet-stream | 2.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Jones | 2026-05-19 06:23:27 | Re: PSQL - prevent describe listing tables that are already in listed schemas |
| Previous Message | vellaipandiyan sm | 2026-05-19 05:42:51 | Review observations for partial REFRESH MATERIALIZED VIEW patc |