Re: Option on `postgres` CLI to shutdown when there are no more active connections?

From: David Barsky <me(at)davidbarsky(dot)com>
To: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Option on `postgres` CLI to shutdown when there are no more active connections?
Date: 2025-10-14 21:40:45
Message-ID: CAPR5_5rvpF+vVnexG6CRoN6DNhM3RReQvuHNJC04OpgVujOArg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

> If testing is all scripted, then why not put "pg_ctl stop" at the end of
the script?

Sorry for the delay.

It’s _mostly_ scripted, but two major reasons:

1. If that script is cancelled or interrupted for any reason, it’s possible
that
`pg_ctl stop` won't be called and I'd have a leaked process. I could
mitigate
this by calling `pg_ctl stop` at the *start* of the script, but that
adds a
bit of latency I'd prefer to avoid.
2. It's a pain to hook that script up to our IDEs in a semi-centralized
manner
(I extended rust-analyzer's test runner to support non-standard build
systems
and I never really got non-standard build systems working with
debuggers).
Even if we eat the pain, the aforementioned latency coming from `pg_ctl
stop`
is a bit annoying.
1. For context, rust-analyzer has a nice "runnables" feature that makes
it
possible to run a test directly from within an IDE. Other language
servers/IDEs have similar functionality, but they're heavily biased
to use
language-idiomatic tools and make it a pain to override build
tools/runnables. Besides, in my experience working on IDEs for a large
tech company (and collecting a _lot_ of logs/telemetry...), it's
_extremely_ rare for people to configure their editors: they're
overwhelmingly stock.

I'm also of the mind that there's some elegance to `pg_ctl start
--exit-mode=smart`: no matter how the test script is interrupted or
cancelled, I
can run it again and guarantee that there will be *no* leaked processes or
non-idempotency because the postmaster handles it. That said, looking over
the
`postmaster.c` source, it seems like there isn't any bookkeeping of children
starting/exiting, so there isn't really any reference counting of
connections
there. I'd be happy to add it, but I _do not_ trust myself to write correct
C!

Anyways, I think this relatively small tweak can make a pretty meaningful
impact
in the end-developer experience of programming against Postgres, especially
in
setups that would like to minimize cross-language scripting/dependencies.
However, I also understand that this isn't exactly how Postgres might be
commonly used on these mailing lists.

—David

On Oct 13, 2025 at 1:27:17 PM, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:

> On Mon, Oct 13, 2025 at 3:19 PM David Barsky <me(at)davidbarsky(dot)com> wrote:
> [snip]
>
>> Anyways, I'll try to get at what motivated this whole discussion: would
>> there be
>> community opposition to adding a CLI flag that'd exit/shutdown all
>> Postgres
>> processes once all pending connections close? E.g., something similar to
>> SQL
>> Server's `auto_close` in the vein of `postgres
>> -c "auto_close_after=100"` or `pg-ctl start --exit-mode=smart`?
>>
>
> If testing is all scripted, then why not put "pg_ctl stop" at the end of
> the script?
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bird 2025-10-15 02:42:01 Re: Option on `postgres` CLI to shutdown when there are no more active connections?
Previous Message Nathan Bossart 2025-10-14 21:32:55 Re: Clarification on Role Access Rights to Table Indexes