Re: Fetching timeline during recovery

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
Date: 2020-01-23 16:54:08
Message-ID: 20200123175408.1861ee0d@firost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

Attachment Content-Type Size
0001-v2-Always-expose-available-stats-from-wal-receiver.patch text/x-patch 7.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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