Hi, Thanks for the feedbacks.
On Thu, Jan 22, 2026 at 8:20 AM Michael Paquier <[email protected]> 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
v6-0002-Add-WALRCV_CONNECTING-state-to-walreceiver.patch
Description: Binary data
v6-0001-Doc-document-all-pg_stat_wal_receiver-status-valu.patch
Description: Binary data
