Fujii Masao wrote: > On Thu, Jun 30, 2016 at 10:12 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: > > On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera > > <alvhe...@2ndquadrant.com> wrote: > >> Fujii Masao wrote: > >>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier > >>> <michael.paqu...@gmail.com> wrote: > >>> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao <masao.fu...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
