> 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