MIME-Version: 1.0
References: <CAPR5_5psNqCm1OQr5LL4v6z02Sh=2YHYUg8NY+3xMzfGHfKs+w@mail.gmail.com>
 <ea93ff28-4496-4e3d-a529-191582e02344@aklaver.com> <CAPR5_5q2oCkw19rHb7oy-M0M0purWFM5Jc8ub5xDy_NdhUmRTw@mail.gmail.com>
 <73ff46d2-0bad-4a8d-9928-e494c2d5b0d1@gmail.com> <93702.1760321769@sss.pgh.pa.us>
 <CAFCRh-94eXetAjtCURs5F0JZQr=kso0rVgVSEmWiSD7wA6VcMw@mail.gmail.com>
 <CANzqJaDn_mVi4M0CbKnVNwK9RxYOneoCRmd_d69rbjBrwasuPQ@mail.gmail.com>
 <CAFCRh--P93bF0gpkdvg4MzMNqq5gK=4eWFkmBDR0xw9dmFVAPQ@mail.gmail.com>
 <233155.1760369829@sss.pgh.pa.us> <CAFCRh--_14QR1_=vZvKVZkcA_1LRO-pQd2p6BBRMreyAv2_z6w@mail.gmail.com>
 <CAPR5_5rRYkM9bO=KC_PY-Bj2Fw=t+maEYG+Am-UgaCHRTWyFsg@mail.gmail.com>
In-Reply-To: <CAPR5_5rRYkM9bO=KC_PY-Bj2Fw=t+maEYG+Am-UgaCHRTWyFsg@mail.gmail.com>
From: Dominique Devienne <ddevienne@gmail.com>
Date: Wed, 15 Oct 2025 11:51:32 +0200
Message-ID: <CAFCRh-9LPCnaueSBHTo0ia3K861nxNFfr1mOXWaqC=EDx8+6Ew@mail.gmail.com>
Subject: Re: Option on `postgres` CLI to shutdown when there are no more
 active connections?
To: David Barsky <me@davidbarsky.com>
Cc: Ron Johnson <ronljohnsonjr@gmail.com>, 
	"pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAFCRh-9LPCnaueSBHTo0ia3K861nxNFfr1mOXWaqC%3DEDx8%2B6Ew%40mail.gmail.com>
Precedence: bulk

On Mon, Oct 13, 2025 at 9:19=E2=80=AFPM David Barsky <me@davidbarsky.com> w=
rote:
> > SQLite is fantastic, but it's type-system and lock-model are too restri=
ctive,
> > for a general DB. Similar to David, I think PostgreSQL is close to my i=
deal
> > above, yet still far-enough (and perhaps unwilling enough, as a communi=
ty)
> > to venture into embedded and localhost use-cases, that it's frustrating=
.
>
> Yup, Dominique understands what I want: Postgres' type system, query plan=
ner,
> and locking model, but _shades_ of SQLite's operational properties during=
 local
> development. However, I don't really need Postgres to function like an em=
bedded
> database; I just want the self-contained process cleanup. Connecting to P=
ostgres
> over TCP over localhost is perfect for my use-case

Except postgres is actively hostile to localhost
testing by not supporting ephemeral TCP ports...

Why oh why???
My own servers are unit tested that way.
Why would postgres.exe prevent the use of port 0?

Any work-around that picks a "free" port is racy and ugly.
There's a clean idiom for that, and that's port 0. Why disable it?

I don't get it... --DD

D:\pdgm\trunk\psc2\pgdata>where postgres.exe
D:\pdgm\kits\trunk\postgresql\17.6\Win_x64_10_v17\bin\postgres.exe

D:\pdgm\trunk\psc2\pgdata>where initdb.exe
D:\pdgm\kits\trunk\postgresql\17.6\Win_x64_10_v17\bin\initdb.exe

D:\pdgm\trunk\psc2\pgdata>initdb -D .\test1 -U postgres -A trust
The files belonging to this database system will be owned by user "ddevienn=
e".
...
Success. You can now start the database server using:  pg_ctl -D
^"^.^\test1^" -l logfile start

D:\pdgm\trunk\psc2\pgdata>postgres -D .\test1 -p 0
2025-10-15 09:43:59.293 GMT [42288] FATAL:  0 is outside the valid
range for parameter "port" (1 .. 65535)