Re: Add WALRCV_CONNECTING state to walreceiver

Hi,

Thanks for the feedbacks.

On Thu, Jan 22, 2026 at 8:20 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Jan 21, 2026 at 08:40:16PM +0800, Xuneng Zhou wrote:
> > Please see v5 of the updated patch.
>
> This seems acceptable here, cool.
>
> Something worth a note: I thought that the states of the WAL sender
> were documented already, and I was wrong in thinking that it was the
> case. Sorry. :)
>
> By the way, the list of state values you are specifying in the patch
> is not complete. In theory, we allow all state values like "stopped"
> to show up in a single function call of pg_stat_get_wal_receiver(),
> but you are not documenting all of them.

My concern for not adding it before is that this status could be
invisible to users.
Looking at pg_stat_get_wal_receiver():

if (pid == 0 || !ready_to_display)
PG_RETURN_NULL();

The function returns NULL (no row) when pid == 0.

When the WAL receiver is in WALRCV_STOPPED state (WalRcvDie), pid is set to 0:
walrcv->walRcvState = WALRCV_STOPPED;
walrcv->pid = 0;

So the view returns no row rather than a row with status = 'stopped'.
But for completeness, maybe we should add it.

> Using a list (like with the
> <itemizedlist> markup) would be better.

The states are now wrapped in an itemizedlist.

> The documentation improvement can be treated as a separate change,
> worth its own before adding the new "connecting" state. Could you
> split that into two patches please? That would make one patch for
> the documentation changes with the list of state values that can be
> reported, and a second patch for the new "connecting" state.

The changes have been splitted into two patches as suggested.

--
Best,
Xuneng