Michael Paquier wrote: > On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > Michael Paquier wrote: > >> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera > >> <alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers