Greetings,
* Peter Eisentraut (peter.eisentraut@enterprisedb.com) wrote:
> On 13.04.23 04:45, Yurii Rashkovskii wrote:
> > But getting your agreement is important to get this in; I am willing to
> > play along and resolve both (1) and (2) in one go. As for the
> > implementation approach for (2), which of the following options would
> > you prefer?
> >
> > a) Document postmaster.pid as it stands today
> > b) Expose the port number through pg_ctl (*my personal favorite)
> > c) Redesign its content below line 1 to make it extensible (make unnamed
> > lines named, for example)
> >
> > If none of the above options suit you, do you have a strategy you'd prefer?
>
> 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).
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.
> 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?
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.
Thanks!
Stpehen