Re: Option on `postgres` CLI to shutdown when there are no more active connections? - Mailing list pgsql-general
| From | David Barsky |
|---|---|
| Subject | Re: Option on `postgres` CLI to shutdown when there are no more active connections? |
| Date | |
| Msg-id | CAPR5_5rvpF+vVnexG6CRoN6DNhM3RReQvuHNJC04OpgVujOArg@mail.gmail.com Whole thread Raw |
| In response to | Re: Option on `postgres` CLI to shutdown when there are no more active connections? (Ron Johnson <ronljohnsonjr@gmail.com>) |
| Responses |
Re: Option on `postgres` CLI to shutdown when there are no more active connections?
Re: Option on `postgres` CLI to shutdown when there are no more active connections? |
| List | 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@gmail.com> wrote:
On Mon, Oct 13, 2025 at 3:19 PM David Barsky <me@davidbarsky.com> wrote:[snip]Anyways, I'll try to get at what motivated this whole discussion: would there becommunity opposition to adding a CLI flag that'd exit/shutdown all Postgresprocesses once all pending connections close? E.g., something similar to SQLServer'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!
pgsql-general by date: