Re: primary_conninfo missing from pg_stat_wal_receiver

Michael Paquier wrote:
> On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > Michael Paquier wrote:
> >> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
> >> <alvherre(at)2ndquadrant(dot)com> wrote:
> >> > Also, actually, I see no reason for the conninfo to be shown differently
> >> > regardless of a connection being already established. If we show the
> >> > conninfo that the server is trying to use, it might be easier to
> >> > diagnose a problem. In short, I think this is all misconceived (mea
> >> > culpa) and that we should have two conninfo members in that struct as
> >> > initially proposed, one obfuscated and the other not.
> >>
> >> If the conninfo is leaking an incorrect password, say it has only a
> >> couple of characters of difference with the real one, we'd still leak
> >> information.
> >
> > No, I don't mean to leak any password. It would still be obfuscated,
> > but all other details would be there (anything with default values).
>
> OK. There is no need to use two fields by the way. The WAL receiver
> makes no attempts to reconnect with the same string and leaves immediately
> should a connection fail.

Yes, but the question is what happens if somebody queries before
walreceiver attempts to connect, no? That's the case where the current
code loops.

> >> The window where the information of a failed connection is rather
> >> limited as well, the WAL receiver process shuts down immediately and
> >> would reset its PID to 0, hiding the information anyway.
> >
> > Some of the details are set by the startup process, such as the start
> > LSN etc, not the walreceiver. Only the PID is reset AFAICS.
>
> Yeah, I know. Now my opinion regarding this view is that we should
> show information about a currently-working WAL receiver, and that it
> has nothing to do with reporting information of its previous startup state.
> That's more consistent with the WAL sender.

Okay, that argument I buy.

I suppose this function/view should report no row at all if there is no
wal receiver connected, rather than a view with nulls.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services