Le jeu. 3 août 2023 à 15:17, Christoph Moench-Tegeder <c...@burggraben.net> a écrit :
> ## Laetitia Avrot (laetitia.av...@gmail.com): > > > For my customer, their use case is to be able from an SQL client to > double > > check they're on the right host before doing things that could become a > > production disaster. > > Why not use cluster_name for that? Even if it may not be relevant > for their setup, there might be multiple clusters on the same host > (multiple clusters with the same hostname) or you database could be > hiding behind some failover/loadbalancer mechanism (multiple hostnames > in one cluster), thus using the hostname to identify the cluster is > totally not universal (the same goes for the monitoring/metrics > stuff). And there's of course inet_server_addr(), if you really > need to double-check if you're connected to the right machine. > Hello Christoph, I understand your point and sure enough, my customer could set and use the cluster_name for that purpose. I totally disagree with using inet_server_addr() for that purpose as there are so many different network settings with VIPs and so on that it won't help. Also, a socket connection will give a NULL value, not that it's *that* bad because if it's a socket, you're running locally and could still use `\! ifconfig`, but it does not work on some configurations (docker for example). Also, most humans will find it easier to memorize a name than a number and that's one of the reasons why we remember websites' URLs instead of their IP. I still disagree with the monitoring part. A good monitoring tool will have to reconcile data from the OS with data from the Postgres cluster. So that, we kind of need a way for the monitoring tool to know on which host this particular cluster is running and I think it's smarter to get this information from the Postgres cluster. Of course, I do love the idea that Postgres is agnostic from where it's running, but I don't think this new function removes that. Have a nice day, Lætitia
