From: | Laetitia Avrot <laetitia(dot)avrot(at)gmail(dot)com> |
---|---|
To: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding a pg_servername() function |
Date: | 2023-08-04 08:26:46 |
Message-ID: | CAB_COdj3vV6BOHzywx+5+QD6=dyZ+HsiGVQdknLAm6qxqoJYAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le jeu. 3 août 2023 à 15:17, Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>
a écrit :
> ## Laetitia Avrot (laetitia(dot)avrot(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2023-08-04 08:41:56 | Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning |
Previous Message | Peter Smith | 2023-08-04 07:45:07 | Re: Adding a LogicalRepWorker type field |