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
