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!
>
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 |