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

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com>, Yurii Rashkovskii <yrashk(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PATCH] Allow Postgres to pick an unused port to listen
Date: 2023-04-20 11:22:07
Message-ID: CAJ7c6TPBMQ9j8hB-UaHi43Amk=Pgt6V+3NYMjamBTzLg=rycqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2023-04-20 11:41:17 Re: [PoC] pg_upgrade: allow to upgrade publisher node
Previous Message Amit Kapila 2023-04-20 11:16:38 Re: Initial Schema Sync for Logical Replication