Re: [PATCH] Allow Postgres to pick an unused port to listen - Mailing list pgsql-hackers
| From | Yurii Rashkovskii |
|---|---|
| Subject | Re: [PATCH] Allow Postgres to pick an unused port to listen |
| Date | |
| Msg-id | CA+RLCQzRGBs5UoV=XL_i1tPkbkt5wme1s0u3ibemWz1KEQT_gg@mail.gmail.com Whole thread Raw |
| In response to | Re: [PATCH] Allow Postgres to pick an unused port to listen (Stephen Frost <sfrost@snowman.net>) |
| Responses |
Re: [PATCH] Allow Postgres to pick an unused port to listen
|
| List | pgsql-hackers |
Stephen,
> You could just drop another file into the data directory that just contains
> the port number ($PGDATA/port). However, if we ever do multiple ports, that
> would still require a change in the format of that file, so I don't know if
> that's actually better than a).
I find it difficult to get anything done under the restriction of "what if we ever need to change X?" as it is difficult to address something that doesn't exist or hasn't been planned.
A fine and delicate balance of anticipating what may happen theoretically and what's more likely happen is an art. It's also important to consider the impact of a breaking change. It's one thing if we have to break, say, an SQL function signature or SQL syntax itself, and another if it is a relatively small feature related to the administration of a server (in this case, more like scripting a test bench).
If we did a port per line then it wouldn't be changing the format of the
first line, so that might not be all that bad.
If we consider this path, then (if we assume the format of the file is still to be private), we can make the port line accept multiple ports using a delimiter like `:` so that the next line still remains the same.
That being said, if the format is private to Postgres, it's all minor considerations.
> I don't think involving pg_ctl is necessary or desirable, since it would
> make any future changes like that even more complicated.
I'm a bit confused by this- if pg_ctl is invoked then we have
more-or-less full control over parsing and reporting out the answer, so
while it might be a bit more complicated for us, it seems surely simpler
for the end user. Or maybe you're referring to something here that I'm
not thinking of?
I would love to learn about this as well.
Independent of the above though ... this hand-wringing about what we
might do in the relative near-term when we haven't done much in the past
many-many years regarding listen_addresses or port strikes me as
unlikely to be necessary. Let's pick something and get it done and
accept that we may have to change it at some point in the future, but
that's kinda what major releases are for, imv anyway.
That's how I see it, too. I tried to make this change as small as possible to appreciate the fact that all of this may change one day if or when that portion of Postgres will be due for a major redesign. I'd be happy to contribute to that process, but in the meantime, I am looking for the simplest reasonable way to achieve a relatively specific use case.
Personally, I am fine with reading the `.pid` file and accepting that it _may_ change in the future; I am also fine with amending the patch to add functionality to pg_ctl or adding a new file.
To keep everybody's cognitive load low, I'd rather not flood the thread with multiple alternative implementations (unless that's desirable) and just go for something we can agree on.
(I consider this feature so small that it doesn't deserve such a lengthy discussion. However, I also get Tom's point about how we document this feature's use, which is very valid and valuable. If it was up to me entirely, I'd probably just document `postmaster.pid` and call it a day. If it ever breaks, that's a major release territory. Otherwise, amending `pg_ctl` to access information like this in a uniform way is also a good approach if we want to keep the format of the pid file private.)
Y.
pgsql-hackers by date: