> The question is: what is the problem we want to solve?
The client_hostname is useful for TCP/IP connections because it
indicates which row of the view is related to which standby server. I
would like to have the same for UNIX domain socket case as well.
> Ishii-san asked
> for a socket path. If we have already figured out the replica (via
> application_name), use the replica PID to find the socket path.
Well, I would like to avoid to use application_name if possible.
> A new
> column as suggested by Tom could show the desired info. Is it *really*
> useful? I mean, how many setups have master and replica in the same
> server?
For developing/testing purpose I often create master and some replicas
in the same server. The same technique is used in a regression test
for Pgpool-II.
> For a socket connection, directory is important and that
> information I can get from unix_socket_directories parameter (I've
> never seen a setup with multiple socket directories).
Yes, it could be a way to get the same information that
sockaddr_un.sunpath used to provide. But now I realize that it's not
what I want. What I actually wanted was, which row of the view is
related to which standby server. So what I really need is the standby
server's accepting socket path, *not* primary server's. Currently it
seems it's not possible except using the application_name
hack. Probably cleaner way would be walreciver provides socket path
information in startup packet and walsender keeps the info in shared
memory so that pg_stat_replication view can use it later on.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp