Michael Paquier wrote:
> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
> <alvherre@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).
> 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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services