Re: primary_conninfo missing from pg_stat_wal_receiver

Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 10:12 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera
> > <alvherre(at)2ndquadrant(dot)com> wrote:
> >> Fujii Masao wrote:
> >>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
> >>> <michael(dot)paquier(at)gmail(dot)com> wrote:
> >>> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> >>
> >>> >> ISTM that we will never be able to get out of this loop if walreceiver
> >>> >> fails to connect to the master (e.g., password is wrong) after we enter
> >>> >> this loop.
> >>> >
> >>> > Wouldn't it be cleaner to just return an error here instead of retrying?
> >>>
> >>> I prefer to return NULL. Now NULL is returned when walreceiver's pid is 0.
> >>> We can just change this logic so that NULL is returned pid is 0 OR the
> >>> flag is false.
> >>
> >> For the conninfo only, or for everything?
> >
> > All of them. If this connstr is not ready for display, the WAL
> > receiver does not have a proper connection yet, so there is nothing
> > worth showing anyway to the user.
>
> +1

slotname seems worth showing. And if this process just started after
some other process was already receiving, then the LSN fields surely can
have useful data too.

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.

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