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

On 10/8/25 12:39, David Barsky wrote:
> Hiya folks,
> 
> I'm a bit of a newcomer when it comes to PostgreSQL, so I apologize if 
> this is
> the wrong mailing list. Anyways, my two questions:
> 
> 1. Is there any interest in adding a command line option to the 
> `postgres` CLI
>     that shuts down the PostgreSQL instance once (and optionally cleans 
> up the
>     data directory) once all connections have disconnected?

https://www.postgresql.org/docs/current/app-pg-ctl.html

"
stop mode shuts down the server that is running in the specified data 
directory. Three different shutdown methods can be selected with the -m 
option. “Smart” mode disallows new connections, then waits for all 
existing clients to disconnect. If the server is in hot standby, 
recovery and streaming replication will be terminated once all clients 
have disconnected. “Fast” mode (the default) does not wait for clients 
to disconnect. All active transactions are rolled back and clients are 
forcibly disconnected, then the server is shut down. “Immediate” mode 
will abort all server processes immediately, without a clean shutdown. 
This choice will lead to a crash-recovery cycle during the next server 
start.
"


>     a. Alternatively, I wouldn't mind accomplishing this via the single-user
>        mode if it could accept the binary/wire protocol in addition to the
>        current text protocol.
> 2. Are there plans for having any additional table access methods beyond 
> `HEAP`
>     shipping as part of Postgres? I'd love to have something that's purely
>     in-memory to bypass the tempdir dance that I'm currently doing.
> For context, I'm trying to make it easier to test our application against a
> live, actual PostgreSQL instance and make the experience feel a lot like
> sqlite's embedded/in-memory workflow. Today, we've gotten really great

Postgres is not an embedded database, if you want that experience then 
use a database that is designed to be embedded.

> latencies via test transactions, but I'd also like to ensure that there 
> aren't
> any orphaned Postgres processes at the end of a test run or without 
> requiring
> the user to start an instance of Postgres prior to running the tests.
> 
> Warmest regards,
> David


-- 
Adrian Klaver
adrian.klaver@aklaver.com