Re: Fetching timeline during recovery

At Fri, 3 Jan 2020 16:11:38 +0100, Jehan-Guillaume de Rorthais  wrote in 
> Hi,
> 
> On Mon, 23 Dec 2019 15:38:16 +0100
> Jehan-Guillaume de Rorthais  wrote:
> [...]
> > My idea would be to return a row from pg_stat_get_wal_receiver() as soon as
> > a wal receiver has been replicating during the uptime of the standby, no
> > matter if there's one currently working or not. If no wal receiver is active,
> > the "pid" field would be NULL and the "status" would reports eg. "inactive".
> > All other fields would report their last known value as they are kept in
> > shared memory WalRcv struct.
> 
> Please, find in attachment a patch implementing the above proposal.

At Mon, 23 Dec 2019 15:38:16 +0100, Jehan-Guillaume de Rorthais  wrote in 
>  1. we could decide to remove this filter to expose the data even when no wal
>     receiver is active. It's the same behavior than pg_stat_subscription view.
>     It could introduce regression from tools point of view, but adds some
>     useful information. I would vote 0 for it.

A subscription exists since it is defined and regardless whether it is
active or not. It is strange that we see a line in the view if
replication is not configured. But it is reasonable to show if it is
configured.  We could do that by checking PrimaryConnInfo. (I would
vote +0.5 for it).

>  2. we could extend it with new replayed lsn/tli fields. I would vote +1 for
>     it.

+1. As of now a walsender lives for just one timeline, because it ends
for disconnection from walsender when the master moves to a new
timeline.  That being said, we already have the columns for TLI for
both starting and received-up-to LSN so we would need it also for
replayed LSN for a consistent looking.

The function is going to show "streaming" but conninfo is not shown
until connection establishes. That state is currently hidden by the
PID filtering of the view. We might need to keep the WALRCV_STARTING
state until connection establishes.

sender_host and sender_port have bogus values until connection is
actually established when conninfo is changed. They as well as
conninfo should be hidden until connection is established, too, I
think.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center