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. That's not good IMO based on the concerns raised on this thread. I'd just mark all the fields as NULL in this case and move on. This way the code keeps being simple, and having this information means that the WAL receiver is correctly working. 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. -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers