Yurii Rashkovskii <yrashk@gmail.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?