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

From: Ron Johnson <[email-masked]>
Date: Mon, 13 Oct 2025 16:27:17 -0400

On Mon, Oct 13, 2025 at 3:19 PM David Barsky <[email-masked]> 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!

---

From: David Barsky <[email-masked]>
Date: Tue, 14 Oct 2025 14:40:45 -0700

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

---

From: Bird <[email-masked]>
Date: Wed, 15 Oct 2025 02:42:01 +0000

On October 14, 2025 9:40:45 PM UTC, David Barsky <[email-masked]> wrote:
>   `pg_ctl stop` won't be called and I'd have a leaked process.

bash has EXIT trap you can use to run functions even in the case of interrupts; You can create a wrapper script if its not written in bash.

 I could
>   bit of latency I'd prefer to avoid.

You could also run pg_ctl stop in the background (i.e. in another process). Again, if using bash, you just add & at the end. It should be possible to create processes in any scripting language.

---

From: Thiemo Kellner <[email-masked]>
Date: Wed, 15 Oct 2025 07:47:34 +0200 (GMT+02:00)

14.10.2025 23:49:21 David Barsky <[email-masked]>:

> 1. If that script is cancelled or interrupted for any reason, it’s possible that

As others stated, some shells have the trapping functionality.

> I could mitigate
>    this by calling `pg_ctl stop` at the *start* of the script, but that adds a

I wonder what the reason is to avoid that latency in the script. Spinning down the DB will take time anyway.

Would it be possible to make a procedure run at the start of the DB, like a daemon, checking for the last connection to quit if there has been one, and to shutdown the DB in an ordered manner?

Just my two Rappen