Re: Database in another drive

[Ron Johnson]

On Mon, Oct 13, 2025 at 4:19 PM Arbol One  wrote:

> Is there a way to either create the database or save the data in another
> drive?
>
> I am using Win11, not my choice since 1998, and, not surprisingly, the
> WinOS had a crash;
>

I've been using Windows on (local, telecommuting) corporate PCs for 25
years.  Never has the hardware crashed or Windows become so corrupted that
C: needed to be wiped?


> I lost all kinds of information including PostgreSQL (postgres
> (PostgreSQL) 18.0), its databases, tables, data, etc., what a nightmare!
>

Where are your backups?  Why don't you have backups?


> To not have this happen again, I'd like to create the databases in the E:
> drive or have the tables stored in that drive, please note that I am not
> talking about backing the data in the E: drive, but to actually have the
> databases in the E: drive. Can this be done and is it practical to do this?
>

Of course.  The same way you created them on C:.  Either with a GUI or
command prompt.
mkdir E:\PosgreSQL\data
initdb -k -D  E:\PosgreSQL\data

-- 
Death to , and butter sauce.
Don't boil me, I'm still alive.
 lobster!

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

[Ron Johnson]

On Sat, Oct 11, 2025 at 7:11 PM Adrian Klaver 
wrote:

> 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.
> "
>

I think OP is looking for AUTO_CLOSE, like SQL Server (and Rdb/VMS before
it).  Its only real utility is OP's use-case: a Windows desktop running
local testing.

We in the shell scripting daemon world don't think like that.

-- 
Death to , and butter sauce.
Don't boil me, I'm still alive.
 lobster!

Re: Database in another drive

[John McKown]

https://www.google.com/search?q=create+postgres+database+on+e%3A&oq=create+postgres+database+on+e%3A&gs_lcrp=EgZjaHJvbWUyBggAEEUYOdIBCTI5MjI0ajBqN6gCD7ACAQ&client=ms-android-google&sourceid=chrome-mobile&ie=UTF-8

On Mon, Oct 13, 2025, 15:19 Arbol One  wrote:

> Is there a way to either create the database or save the data in another
> drive?
>
> I am using Win11, not my choice since 1998, and, not surprisingly, the
> WinOS had a crash; I lost all kinds of information including PostgreSQL 
> (postgres
> (PostgreSQL) 18.0), its databases, tables, data, etc., what a nightmare!
> To not have this happen again, I'd like to create the databases in the E:
> drive or have the tables stored in that drive, please note that I am not
> talking about backing the data in the E: drive, but to actually have the
> databases in the E: drive. Can this be done and is it practical to do this?
>
>
>
>
>
>
>

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

[Dominique Devienne]

On Mon, Oct 13, 2025 at 4:16 AM Tom Lane  wrote:
> Rob Sargent  writes:
> > On 10/12/25 16:10, David Barsky wrote:
> >>> Postgres is not an embedded database, if you want that experience then
> >>> use a database that is designed to be embedded.
>
>>> That's fair, especially from an operational standpoint. However, I _think_
>>> Postgres can get really close to an embedded database's development
>>> experience by doing a few tricks that I'll elaborate on later on in this 
>>> email.
>
>> Were I a betting man, I would bet heavily against this community, which
>> prides itself on NOT losing data, allowing an option that would do just that.
>
> But I concur with the point that we're not here to pretend to be an
> embedded database, as there are other projects that do that better
> (for example, our good friends at SQLite).

Heavy user of SQLite here, and I have to disagree Tom.

The main reason PostgreSQL can't be embedded is because
of its process-based model with globals. And perhaps locking
as well. But otherwise it would a dream-come-true for single-user
mode of our app, and for testing as well, I have to agree with David.

Even a localhost-only mode that still functions as a normal cluster
except auth is entirely OS-based and it uses a random port
(or bypasses TCP entirely in a *CROSS*-platform way), based on
which pgdata-directory is used, would be OK.

There's apparently no way to abstract the "transport" between libpq
and the server, must be TCP (or *nix only socket files), cannot be an
in-memory channel (for the embedded non-shared case),
nor shared-memory (for the shared-case across localhost processes).

SQLite is fantastic, but it's type-system and lock-model are too restrictive,
for a general DB. Similar to David, I think PostgreSQL is close to my ideal
above, yet still far-enough (and perhaps unwilling enough, as a community)
to venture into embedded and localhost use-cases, that it's frustrating.

My $0.02. --DD

Re: Database in another drive

[Adrian Klaver]

On 10/13/25 14:57, Ron Johnson wrote:
On Mon, Oct 13, 2025 at 4:19 PM Arbol One > wrote:


Is there a way to either create the database or save the data
in another drive?

I am using Win11, not my choice since 1998, and, not surprisingly,
the WinOS had a crash;


I've been using Windows on (local, telecommuting) corporate PCs for 25 
years.  Never has the hardware crashed or Windows become so corrupted 
that C: needed to be wiped?


Consider yourself having lived a charmed life. You don't want to have to 
restore a Windows machine. The usual method is to start over with an OS 
only disk image and rebuild the user data from backups.



--
Adrian Klaver
adrian.kla...@aklaver.com

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

[Ron Johnson]

On Sat, Oct 11, 2025 at 11:21 PM Adrian Klaver 
wrote:

> On 10/11/25 19:56, Ron Johnson wrote:
> > On Sat, Oct 11, 2025 at 7:11 PM Adrian Klaver  > > wrote:
> >
>
> > I think OP is looking for AUTO_CLOSE, like SQL Server (and Rdb/VMS
> > before it).  Its only real utility is OP's use-case: a Windows
> > desktop running local testing.
>
>  From the original post:
>
> "Is there any interest in adding a command line option to the `postgres`
> CLI"
>
> Which I took to mean:
>
> https://www.postgresql.org/docs/current/app-postgres.html


Yeah.  Something like this, which we don't have:
postgres -c "auto_close=on"

-- 
Death to , and butter sauce.
Don't boil me, I'm still alive.
 lobster!

Enquiry about TDE with PgSQL

[Ashish Mukherjee]

Hello,

Thank you to the group members for the responses to my previous questions
about TDE problems with PgSQL 17.

I would like to enquire that based on the anecdotal experience of group
members, which TDE solution works best for PgSQL 17 databases. The scenario
I have is of a large number of tables (15-20K) and some tables with 100M
tuples each. The total database size is 4TB.

I understand there may be variations and specific testing is required,
however high-level pointers and feedback would be valuable.

Regards,
Ashish

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

[Ron Johnson]

On Mon, Oct 13, 2025 at 3:19 PM David Barsky  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 , and butter sauce.
Don't boil me, I'm still alive.
 lobster!