On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> 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).
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.
>> 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.
--
Michael
