|From:||Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>|
|To:||Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>|
|Cc:||michael(at)paquier(dot)xyz, sfrost(at)snowman(dot)net, masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: Fetching timeline during recovery|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, 07 Jan 2020 15:57:29 +0900 (JST)
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> At Mon, 23 Dec 2019 15:38:16 +0100, Jehan-Guillaume de Rorthais
> <jgdr(at)dalibo(dot)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
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.
> 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
Fixed as well.
Please find the new version of the patch in attachment.
Thank you for your review!
|Next Message||Robert Haas||2020-01-23 17:04:00||Re: making the backend's json parser work in frontend code|
|Previous Message||Alvaro Herrera||2020-01-23 16:49:55||Re: Allow to_date() and to_timestamp() to accept localized names|