On Fri, Dec 22, 2017 at 03:11:07PM +1100, Haribabu Kommi wrote: > Updated patch attached with tests and doc changes.
Thanks for the review.
+ <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.
changed the description and field names also to remote instead of primary.
+ char host[NAMEDATALEN]; + char hostaddr[NAMEDATALEN]; Those two should use NI_MAXHOST as maximum length. getaddrinfo() relies on that.
Corrected.
+ 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().