public inbox for [email protected]help / color / mirror / Atom feed
Re: Option on `postgres` CLI to shutdown when there are no more active connections? 4+ messages / 4 participants [nested] [flat]
* Re: Option on `postgres` CLI to shutdown when there are no more active connections? @ 2025-10-13 20:27 Ron Johnson <[email protected]> 2025-10-14 21:40 ` Re: Option on `postgres` CLI to shutdown when there are no more active connections? David Barsky <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Ron Johnson @ 2025-10-13 20:27 UTC (permalink / raw) To: pgsql-generallists.postgresql.org <[email protected]> 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! ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Option on `postgres` CLI to shutdown when there are no more active connections? 2025-10-13 20:27 Re: Option on `postgres` CLI to shutdown when there are no more active connections? Ron Johnson <[email protected]> @ 2025-10-14 21:40 ` David Barsky <[email protected]> 2025-10-15 02:42 ` Re: Option on `postgres` CLI to shutdown when there are no more active connections? Bird <[email protected]> 2025-10-15 05:47 ` Re: Option on `postgres` CLI to shutdown when there are no more active connections? Thiemo Kellner <[email protected]> 0 siblings, 2 replies; 4+ messages in thread From: David Barsky @ 2025-10-14 21:40 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]> > 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! > ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Option on `postgres` CLI to shutdown when there are no more active connections? 2025-10-13 20:27 Re: Option on `postgres` CLI to shutdown when there are no more active connections? Ron Johnson <[email protected]> 2025-10-14 21:40 ` Re: Option on `postgres` CLI to shutdown when there are no more active connections? David Barsky <[email protected]> @ 2025-10-15 02:42 ` Bird <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Bird @ 2025-10-15 02:42 UTC (permalink / raw) To: [email protected]; David Barsky <[email protected]>; Ron Johnson <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]> On October 14, 2025 9:40:45 PM UTC, David Barsky <[email protected]> wrote: >> 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. 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 >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. 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. ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Option on `postgres` CLI to shutdown when there are no more active connections? 2025-10-13 20:27 Re: Option on `postgres` CLI to shutdown when there are no more active connections? Ron Johnson <[email protected]> 2025-10-14 21:40 ` Re: Option on `postgres` CLI to shutdown when there are no more active connections? David Barsky <[email protected]> @ 2025-10-15 05:47 ` Thiemo Kellner <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Thiemo Kellner @ 2025-10-15 05:47 UTC (permalink / raw) To: [email protected] 14.10.2025 23:49:21 David Barsky <[email protected]>: > 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. 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 > bit of latency I'd prefer to avoid. 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 ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-10-15 05:47 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-10-13 20:27 Re: Option on `postgres` CLI to shutdown when there are no more active connections? Ron Johnson <[email protected]> 2025-10-14 21:40 ` David Barsky <[email protected]> 2025-10-15 02:42 ` Bird <[email protected]> 2025-10-15 05:47 ` Thiemo Kellner <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox