Re: [PATCH] Allow Postgres to pick an unused port to listen

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.