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

Hi Tom,

On Thu, Apr 13, 2023 at 9:17 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Yurii Rashkovskii <yrashk(at)gmail(dot)com> writes:
> > Thank you all for the feedback. It's quite useful. I think it is
> important
> > to separate this into two concerns:
>
> > 1. Letting Postgres pick an unused port.
> > 2. Retrieving the port it picked.
>
> Yeah, those are distinguishable implementation concerns, but ...
>
> > The bottom line is this decouples (1) from (2), and we can resolve them
> > separately if there's too much (understandable) hesitation to commit to a
> > particular approach to it (documenting postmaster.pid, changing its
> format,
> > amending pg_ctl functionality, etc.)
>
> ... AFAICS, there is exactly zero value in committing a solution for (1)
> without also committing a solution for (2). I don't think any of the
> alternative methods you proposed are attractive or things we should
> recommend.
>

I disagree that zero value exists in (1) without (2). As my examples show,
they make it possible to pick a port without synchronization scripting. Are
they perfect? Of course, not. But they are better than lock file-based
scripts IMO. They are not exposed to race conditions.

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?