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

Aleksander,

On Thu, Apr 20, 2023 at 1:22 PM Aleksander Alekseev <
aleksander(at)timescale(dot)com> wrote:

> Hi,
>
> > Also, I don't think there's a case for distributed systems here because
> we're only managing a single computer's resource: the allocation of local
> ports.
>
> I don't suggest building a distributed system but rather using
> well-known solutions from this area. For the described case the
> "resource manager" will be as simple a single Consul instance (a
> single binary file, since Consul is written in Go) running locally.
> The "complexity" would be for the test framework to use a few extra
> REST queries. Arguably not that complicated.
>

Bringing in a process that works over REST API (requiring itself to have a
port, by the way) and increasing the rollout of such an environment is
antithetical to simplicity
and, thus, will make it only worse. If this is the alternative, I'd rather
have a few retries or some other small hacks.

Bringing in a new dependency with Python is also a heavy solution I'd
rather avoid. I find that this is rather a problem with a relatively small
surface. If the patch won't go through,
I'll just find a workaround to live with, but I'd rather stay away from
blowing the development environment out of proportion for something so
minuscule.

>
> > using a KV store to lease a port does not guarantee the port's
> availability
>
> I assume you don't have random processes doing random things (like
> listening random ports) on a CI machine. You know that certain ports
> are reserved for the tests and are going to be used only for this
> purpose using the same leasing protocol.
>

This is intended to be used by CI and development workstations, where all
bets are kind of off.

>
> > For example, I'd suggest adding an option to Postgres to receive sockets
> it should listen [...]
>
> Not sure if I fully understood the idea, but it looks like you are
> suggesting to build in certain rather complicated functionality for an
> arguably rare use case so that a QA engineer didn't have one extra
> small dependency to worry about in this rare case. I'm quite skeptical
> that this is going to happen.
>

My suggestion was to simply allow listening for a wildcard port and be able
to read it out in some way. Nothing particularly complicated. The fact that
the process may die before it is connected to is rather a strange argument
as the same can happen outside of this use case.

--
Y.