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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, Yurii Rashkovskii <yrashk(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Allow Postgres to pick an unused port to listen
Date: 2023-04-12 18:24:30
Message-ID: 1164328.1681323870@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Apr 12, 2023 at 1:56 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah. My main concern here is with limiting our ability to change
>> the pidfile format in future. If we can keep the dependencies on that
>> localized to code we control, it'd be much better.

> I don't know if it's considered officially supported, but I often use
> pg_ctl stop on a directory without worrying about whether I'm doing it
> with the same server version that's running in that directory. I'd be
> reluctant to break that property. So I bet our ability to modify the
> file format is already quite limited.

IMO, the only aspect we consider "officially supported" for outside
use is that the first line contains the postmaster's PID. All the
rest is private (and has changed as recently as v10). Without
having actually checked the code, I think that "pg_ctl stop" relies
only on that aspect, or at least it could be made to do so at need.
So I think your example would survive other changes in the format.

I don't really want external code knowing that line 4 is the port,
because I foresee us breaking that someday --- what will happen
when we want to allow one postmaster to support multiple ports?
Maybe we'll decide that we don't have to reflect that in the
pidfile, but let's not constrain our decisions ahead of time.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2023-04-12 18:24:33 Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security
Previous Message Jacob Champion 2023-04-12 18:23:01 Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security