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