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.
> 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.
If there are random things happening on CI you have no control of, you
are having a problem with the CI infrastructure, not with Postgres.
> 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.
> I am curious, Yurii, is Postgres the only service that need an unused
> port for listening in your testing/application environment? Otherwise,
> how is this handled in other software?
That's a very good point.
To clarify, there is nothing wrong with the patch per se. It's merely
an unreliable solution for a problem it is supposed to address. I
don't think we should encourage the users to build unreliable systems.
--
Best regards,
Aleksander Alekseev
