Re: Fetching timeline during recovery

On Tue, 07 Jan 2020 15:57:29 +0900 (JST)
Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:

> At Mon, 23 Dec 2019 15:38:16 +0100, Jehan-Guillaume de Rorthais
> <jgdr@dalibo.com> 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).

Thanks. I put this on hold for now, I'm waiting for some more opinons as
there's no strong position yet.

> >  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.

I added applied_lsn and applied_tli to the pg_stat_get_wal_receiver function
output columns.

However, note that applying xlog is the responsibility of the startup process,
not the wal receiver one. Is it OK that pg_stat_get_wal_receiver
returns stats not directly related to the wal receiver?

> 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.

Indeed, fixed.

> 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.

Fixed as well.

Please find the new version of the patch in attachment.

Thank you for your review!