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
[email protected]
