Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v7ikH-006qVq-P6 for pgsql-general@arkaria.postgresql.org; Sat, 11 Oct 2025 23:11:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v7ikF-00HKEn-46 for pgsql-general@arkaria.postgresql.org; Sat, 11 Oct 2025 23:11:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v7ikD-00HKEb-Ui for pgsql-general@lists.postgresql.org; Sat, 11 Oct 2025 23:11:23 +0000 Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1v7ikC-001GU6-36 for pgsql-general@lists.postgresql.org; Sat, 11 Oct 2025 23:11:21 +0000 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 017787A0081; Sat, 11 Oct 2025 19:11:19 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Sat, 11 Oct 2025 19:11:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1760224279; x=1760310679; bh=22iwASYcTZFFgGZyWbPNeISOZV8/j4MGkxUuqu0s83o=; b= eVucLpqN73coaH88C3f7VwVSYa7zE/uoY9Jysu44iNeb8lpoZ0u9eyO9ZxZG1GF4 2PaWsFKof46PFX2hNNPD2gyDdJM1ISeN707JTEUHbfjK8L6Om+Xef1btSv45+V7l YmoIk7R+LDuLq01YE4QcpfCL/+Bv64ahJfG4wGL751Nc92JKdbMrXsbRI7/i9vHy UC1vONoSyf7dvAy5+2SfzsUwsS+9NbZziIMi8CTqwQS+WWthqUBEUbyhXN9KIHOl 4O5IrPZgmzLudAeavc1KkABrqbOQGB393Nuy7ZRb9N857VVZmnF5c4bSQeHQ033O +I2td7mIlP1td6mtydEtBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1760224279; x=1760310679; bh=2 2iwASYcTZFFgGZyWbPNeISOZV8/j4MGkxUuqu0s83o=; b=q3eFZpAcm3XzzPa9F WiB0wd7THiKuz5CZq7DJM8KW0uteb6e2tN28YMmgYoWal0OX0U6S7saNq3LIaeOc FpFbeItbhe8UO+2PRoC5x+tu5XPY6YXD5GBxjL5l1QSFY+bkEqfDjz9VWJpxCe+j EXJG/OqIm5Z3oUzKWS0SaRyojGuS/Z4v1h4M9qIAgSdjU378Hi0gqYDMWrScRFSF kgp4LtqRhyIF55CFkQyOfDCCqiF65QLpggqBLEibT+Feyb2k9Hco4RyzTAVXXxcX SRrxyzAs3dpQiIK7eqep80nBUDxy2u7ydRzEp77ifcc9csUJY488NEcMANH0U9K/ 6mKnw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduudefudekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertd dtvdejnecuhfhrohhmpeetughrihgrnhcumfhlrghvvghruceorggurhhirghnrdhklhgr vhgvrhesrghklhgrvhgvrhdrtghomheqnecuggftrfgrthhtvghrnhepleegveekkeekue eigfdtveeileeuhfefudefteekjeffkeejueejheegheegkedtnecuffhomhgrihhnpehp ohhsthhgrhgvshhqlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhm pdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehmvg esuggrvhhiuggsrghrshhkhidrtghomhdprhgtphhtthhopehpghhsqhhlqdhgvghnvghr rghlsehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 11 Oct 2025 19:11:19 -0400 (EDT) Message-ID: Date: Sat, 11 Oct 2025 16:11:18 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Option on `postgres` CLI to shutdown when there are no more active connections? To: David Barsky , pgsql-general@lists.postgresql.org References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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