Re: Enhance pg_stat_wal_receiver view to display connected host

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: Enhance pg_stat_wal_receiver view to display connected host
Дата
Msg-id CAJrrPGdTwBbZk=bSwBmeCnaAsgQxV9bFJUGj_3mse9sE97wQ2w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Enhance pg_stat_wal_receiver view to display connected host  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: Enhance pg_stat_wal_receiver view to display connected host
Re: Enhance pg_stat_wal_receiver view to display connected host
Список pgsql-hackers

[ Including Hackers as earlier mail mistakenly removed it ]

On Tue, Jan 16, 2018 at 2:55 PM, Michael Paquier <michael.paquier@gmail.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: sanyam jain
Дата:
Сообщение: Setting BLCKSZ 4kB
Следующее
От: Yoshimi Ichiyanagi
Дата:
Сообщение: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory