Re: Enhance pg_stat_wal_receiver view to display connected host

On Wed, Jan 10, 2018 at 04:10:35PM +1100, Haribabu Kommi wrote:
> On Tue, Jan 9, 2018 at 12:15 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
> wrote:
>> Hm. Any users of psql's PROMPT would be equally confused, and this can
>> actually lead to more confusion from the user prospective I think than
>> just pg_stat_wal_receiver. If you take the case of Haribabu from
>> upthread with say this bit in psqlrc:
>> \set PROMPT1 '[host=%M;port=%>]=%# '
>>
>> Then you get on HEAD the following set of results using different
>> connection strings:
>> 1) host=localhost,localhost hostaddr=127.0.0.1,127.0.0.1 port=5432,5433
>> [host=localhost,localhost;port=5432]=#
>>
>> 2) host=localhost,localhost port=5432,5433
>> [host=localhost;port=5432]=#
>>
>> 3) hostaddr=127.0.0.1,127.0.0.1 port=5432,5433
>> [host=[local];port=5432]=#
>>
>> 4) host=/tmp,tmp hostaddr=127.0.0.1,127.0.0.1
>> [host=[local:/tmp,tmp];port=5432]=#
>>
>> So for cases 2) and 4), mixing both hostaddr and host is hurting the
>> experience. The documentation in [1] also specifies that if both host
>> and hostaddrs are specified then host is ignored. The same rule applies
>> for multiple values so for 2) and 4) the correct values ought to be
>> "local" for both of them. This would be more consistent with the pre-9.6
>> behavior as well.
>>
>
> I think you mean to say for the cases 1) and 4)? because those are the
> cases where it differs with pre-9.6 behavior.

Sure, sorry for the mistake. That's indeed what I meant.

> With the attached patch of changing PQhost() to return the host if
> exists, irrespective of the connection type will bring back the
> pre-9.6 behavior.
>
> 1) host=localhost,localhost hostaddr=127.0.0.1,127.0.0.1 port=5432,5433
> [host=localhost;port=5432]=#
>
> 4) host=/tmp,tmp hostaddr=127.0.0.1,127.0.0.1
> [host=[local];port=5432]=#
>
> Even for default unix domain socket connection,
> conn->connhost[conn->whichhost].host
> is filled with the details, but not the global member. So no need of
> checking global member and returning the same in PQhost() function.

Thanks for the patch and the investigation, this visibly points out to
the fact that 11003eb5 did not get it completely right either. I am
adding Robert in CC for some input on the matter. To me, this looks like
a bug that should be applied down to v10. I think that it would be better
to spawn a new thread as well to raise awareness on the matter. This is
quite different than the patch you are presenting here. What do you
think?

I have redone my set of previous tests and can confirm that PQhost is
behaving as I would expect it should, and those results are the same as
yours.

With your patch, please note also that the SSL test suite does not
complain, which is an excellent thing!
--
Michael