| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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 07:53:38 |
| Message-ID: | 75CDE990-29D5-4D5C-BFE1-3840F19C0163@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On May 20, 2026, at 12:10, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, May 20, 2026 at 09:47:40AM +0800, Chao Li wrote:
>> I just read v2, and it is actually the first solution I tried. The
>> reason I gave up on that approach and switched to the implementation
>> in v1 is that it may wrongly report last_msg_send_time,
>> last_msg_receipt_time, and latest_end_time.
>
> As of the code, we have the following at the top of WalReceiverMain()
> before the first connection attempt:
> /* Initialise to a sanish value */
> now = GetCurrentTimestamp();
> walrcv->lastMsgSendTime =
> walrcv->lastMsgReceiptTime = walrcv->latestWalEndTime = now;
>
Was that okay because walrcv->ready_to_display was false, so the sane initial value would not show up through pg_stat_wal_receiver?
> And the state of v2 is actually fine, because we finish by reporting
> in the SQL calls values that represent the state the WAL receiver is
> initialized at based on what the code does. It would be IMO an issue
> to hide this information, as they can offer hits about the moment when
> we've begun a connection.
> --
> Michael
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.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-05-20 07:54:06 | Re: [PATCH] Fix REPACK decoding worker not cleaned up on FATAL exit |
| Previous Message | Jim Jones | 2026-05-20 07:30:48 | Re: PSQL - prevent describe listing tables that are already in listed schemas |