Re: [PATCH] Allow Postgres to pick an unused port to listen - Mailing list pgsql-hackers

From Yurii Rashkovskii
Subject Re: [PATCH] Allow Postgres to pick an unused port to listen
Date
Msg-id CA+RLCQyMuPj8O7ooqUuFU39zWfoygsrD4VC+yVmqhHV0zGjLFg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Allow Postgres to pick an unused port to listen  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Aleksander,

On Thu, Apr 20, 2023 at 1:22 PM Aleksander Alekseev <aleksander@timescale.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.

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Note new NULLS NOT DISTINCT on unique index tutorial page
Next
From: Melanie Plageman
Date:
Subject: Re: Should we put command options in alphabetical order in the doc?