On Fri, Dec 22, 2017 at 03:11:07PM +1100, Haribabu Kommi wrote:
> Updated patch attached with tests and doc changes.

+    <row>
+     <entry><structfield>primary_hostname</structfield></entry>
+     <entry><type>text</type></entry>
+     <entry>Host name of the primary connected by this WAL receiver</entry>
+    </row>
+    <row>
+     <entry><structfield>primary_hostaddr</structfield></entry>
+     <entry><type>text</type></entry>
+     <entry>Host address of the primary connected by this WAL receiver</entry>
+    </row>
+    <row>
+     <entry><structfield>primary_port</structfield></entry>
+     <entry><type>integer</type></entry>
+     <entry>port number of the primary connected by this WAL receiver</entry>
+    </row>
A WAL receiver could be connected to a standby as well with cascading
replication, so "primary" does not sound like a term adapted to me.
Why not just saying "XXX of the PostgreSQL instance this WAL receiver is
connected to"? Similarly the field names don't seem adapted to me. Would
"remote" be more adapted? Other ideas are of course welcome.

+       char            host[NAMEDATALEN];
+       char            hostaddr[NAMEDATALEN];
Those two should use NI_MAXHOST as maximum length. getaddrinfo() relies on
that.

+       retval =  PQconnectedhostinfo(conn->streamConn, PQ_HOST_ADDRESS);
+       if (retval)
+               *hostaddr = pstrdup(retval);
Yes, going through PQconnectedhostinfo() is a good idea at the end of
the day, as well as keeping one API with libpqrcv_get_conninfo().
-- 
Michael

Attachment: signature.asc
Description: PGP signature

Reply via email to