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: 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-19 21:44:21
Message-ID: CAJ7c6TOVs3yF_iDqh+RobkdceZbAx2C6Mubd8uXYSQ0kmF8Fvg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Here are my two cents.

> > I would like to suggest a patch against master (although it may be worth
> > backporting it) that makes it possible to listen on any unused port.
>
> I think this is a bad idea, mainly because this:
>
> > Instead, with this patch, one can specify `port` as `0` (the "wildcard"
> > port) and retrieve the assigned port from postmaster.pid
>
> is a horrid way to find out what was picked, and yet there could
> be no other.

What personally I dislike about this approach is the fact that it is
not guaranteed to work in the general case.

Let's say the test framework started Postgres on a random port. Then
the framework started to do something else, building a Docker
container for instance. While the framework is busy PostgreSQL crashes
(crazy, I know, but not impossible). Both PID and the port will be
reused eventually by another process. How soon is the implementation
detail of the given OS and its setting.

A bullet-proof approach would be (approximately) for the test
framework to lease the ports on the given machine, for instance by
using a KV value with CAS support like Consul or etcd (or another
PostgreSQL instance), as this is done for leader election in
distributed systems (so called leader lease). After leasing the port
the framework knows no other testing process on the given machine will
use it (and also it keeps telling the KV storage that the port is
still leased) and specifies it in postgresql.conf as usual.

I realize this is a complicated problem to solve in a general case,
but it doesn't look like the proposed patch is the right solution for
the named problem.

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-04-19 21:45:41 Re: Should we put command options in alphabetical order in the doc?
Previous Message Melanie Plageman 2023-04-19 21:33:47 Re: Should we put command options in alphabetical order in the doc?