Re: Enhance pg_stat_wal_receiver view to display connected host

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: Enhance pg_stat_wal_receiver view to display connected host
Date: 2018-01-16 06:56:22
Message-ID: CAJrrPGdTwBbZk=bSwBmeCnaAsgQxV9bFJUGj_3mse9sE97wQ2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[ Including Hackers as earlier mail mistakenly removed it ]

On Tue, Jan 16, 2018 at 2:55 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Mon, Jan 15, 2018 at 05:51:58PM +1100, Haribabu Kommi wrote:
> > Instead of effective_conninfo, I changed the column name as
> > remote_serve_info and
> > display only the host, hostaddr and port details. These are the only
> values
> > that differs
> > with each remote connection.
>
> I agree that it is pointless to show duplication between both
> strings. The differences would be made harder to catch.
>
> +PQconninfoOption *
> +PQeffectiveConninfo(PGconn *conn)
> +{
> + PQExpBufferData errorBuf;
> + PQconninfoOption *connOptions;
> +
> + if (conn == NULL)
> + return NULL;
>
> Shouldn't this check for CONNECTION_BAD as well and return NULL?
>

OK. I will update it.

> If I use something like "port=5432 host=/tmp" as connection string, then
> PQeffectiveConninfo gives me the following with hostaddr being weird:
> host=/tmp hostaddr=(null) port=5432
> This should show an empty hostaddr value.
>

I will correct it.

> + <entry><structfield>remote_server_info</structfield></entry>
> + <entry><type>text</type></entry>
> + <entry>
> + Effective remote server connection info string used by this WAL
> receiver.
> + </entry>
> "Effective" is not a precise term. What about just telling that this is
> the set of parameters used for hte active connection, and that this
> value should be the one used when using multiple host, hostaddr, and
> ports.
>

OK. I will update it.

Note that I still find this API confusing, it seems to me that just
> sorting out the confusion problems with PQhost and then use it would be
> more simple.
>

OK, Understood. Even if the confusion problems with PQhost that are
discussed in [1] are solved, we need two new API's that are required to\
display the proper remote server details.

PQhostNoDefault - Similar like PQhost but doesn't return default host
details.

Displaying default value always some confuse even if the user doesn't
provide
the host details, so to avoid that confusion, we need this function.

PQhostaddr - Return hostaddr used in the connection.

Without PQhostaddr() function, for the connections where the host is not
specified, it will be difficult to find out to remote server.

With the above two new API's we can display either string or individual
columns
representation of remote server.

comments?

Regards,
Hari Babu
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yoshimi Ichiyanagi 2018-01-16 07:00:48 [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory
Previous Message sanyam jain 2018-01-16 06:50:05 Setting BLCKSZ 4kB