Re: Adding a pg_servername() function
| От | Laetitia Avrot |
|---|---|
| Тема | Re: Adding a pg_servername() function |
| Дата | |
| Msg-id | CAB_COdi_gxh5OSZX0vvH_1SgdS7VOOWn_WrXS7O7_c5PMdY1ww@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Adding a pg_servername() function (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Adding a pg_servername() function
(Jimmy Angelakos <jimmy.angelakos@enterprisedb.com>)
|
| Список | pgsql-hackers |
Dear Tom,
Thank you for your interest in that patch and for taking the time to point out several things that need to be better. Please find below my answers.
I actually do object to this, because I think the concept of "server
name" is extremely ill-defined and if we try to support it, we will
forever be chasing requests for alternative behaviors.
Yes, that's on me with choosing a poor name. I will go with pg_gethostname().
Just to start
with, is a prospective user expecting a fully-qualified domain name
or just the base name? If the machine has several names (perhaps
associated with different IP addresses), what do you do about that?
I wouldn't be too surprised if users would expect to get the name
associated with the IP address that the current connection came
through. Or at least they might tell you they want that, until
they discover they're getting "localhost.localdomain" on loopback
connections and come right back to bitch about that.
If there is a gap between what the function does and the user expectations, it is my job to write the documentation in a more clear way to set expectations to the right level and explain precisely what this function is doing. Again, using a better name as pg_gethostname() will also help to remove the confusion.
Windows likely adds a whole 'nother set of issues to "what's the
machine name", but I don't know enough about it to say what.
Windows does have a similar gethostname() function (see here: https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-gethostname).
I think the upthread suggestion to use cluster_name is going to
be a superior solution for most people, not least because they
can use it today and it will work the same regardless of platform.
I don't think cluster_name is the same as hostname. True, people could use that parameter for that usage, but it does not feel right to entertain confusion between the cluster_name (which, in my humble opinion, should be different depending on the Postgres cluster) and the answer to "on which host is this Postgres cluster running?".
> (*) But we should think about access control for this. If you're in a
> DBaaS environment, providers might not like that you can read out their
> internal host names.
There's that, too.
Of course, this function will need special access and DBaaS providers will be able to not allow their users to use that function, as they already do for other features. As I said, the patch is only at the stage of POC, at the moment.
Le mer. 9 août 2023 à 18:31, Tom Lane <tgl@sss.pgh.pa.us> a écrit :
One concrete reason why I am doubtful about this is the case of
multiple PG servers running on the same machine. gethostname()
will be unable to distinguish them.
And that's where my bad name for this function brings confusion. If this function returns the hostname, then it does seem totally legit and normal to get the same if 3 Postgres clusters are running on the same host. If people want to identify their cluster, they should use cluster_name. I totally agree with that.
Why do I think this is useful?
1- In most companies I've worked for, people responsible for the OS settings, Network settings, and database settings are different persons. Also, for most companies I've worked with, maintaining their inventory and finding out which Postgres cluster is running on which host is still a difficult thing and error-prone to do. I thought that it could be nice and useful to display easily for the DBAs on which host the cluster they are connected to is running so that when they are called at 2 AM, their life could be a little easier.
2- In addition, as already pointed out, I know that pg_staviz (a monitoring tool) needs that information and uses this very dirty hack to get it (see https://github.com/vyruss/pg_statviz/blob/7cd0c694cea40f780fb8b76275c6097b5d210de6/src/pg_statviz/libs/info.py#L30)
CREATE TEMP TABLE _info(hostname text);
COPY _info FROM PROGRAM 'hostname';
3- Last but not least, as David E. Wheeler had created an extension to do so for Postgres 9.0+ and I found out a customer who asked me for this feature, I thought there might be out there more Postgres users who could find this feature helpful.
I'm sorry if I'm not making myself clear enough about the use cases of that feature. If you still object to my points, I will simply drop this patch.
Have a nice day,
Lætitia
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Masahiko SawadaДата:
Сообщение: Re: [PoC] pg_upgrade: allow to upgrade publisher node