Re: Fix pg_stat_wal_receiver to show CONNECTING status

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Subject: Re: Fix pg_stat_wal_receiver to show CONNECTING status
Date: 2026-05-20 20:43:52
Message-ID: ag4dCGAPBc5VFhCi@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
>
> But I think it might be useful to show the *_lsn and *_tli values in
> CONNECTING state if they are available.

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-Leds9HQNM6kJnto7RFNhUg@mail.gmail.com

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2026-05-20 21:17:20 Re: Fix SPLIT PARTITION bound-overlap bug and other improvements
Previous Message Alexander Korotkov 2026-05-20 20:29:07 Re: Fix SPLIT PARTITION bound-overlap bug and other improvements