Re: stupid question - Mailing list pgsql-novice

From Michael Glaesemann
Subject Re: stupid question
Date
Msg-id 48992262-3BEA-11D8-A298-000A95C88220@myrealbox.com
Whole thread Raw
In response to Re: stupid question  (rhkelly <rhkelly@myrealbox.com>)
Responses Re: stupid question
List pgsql-novice
Hello, fellow myrealbox user!

On Dec 31, 2003, at 4:09 PM, rhkelly wrote:

>> On Fri, 26 Dec 2003, Bryan Irvine wrote:
>>
>>> Maybe this sounds stupid, but, where is the actual database file?
>>> I'm
>>> sure there's a file that is the actual DB, but what/where?
>> nope ... depending on what version of postgresql you are running, the
>> newer ones store it in ${PGDATA}/base/<OID>, under which, there are
>> indivicudal files for system tables, indices and tables themselves ...
>
> Is there a Postgress documentation section somewhere that
> would tell me the following:
>
> 1) the exact correspondence of the files and tables, indices etc.
>
> 2) what are the safe filesystem operations on those files
> (individual file backup/recovery, moving of files
> between different postgress computers/installations etc.?

Not to be contrary, but why would you want to know this? The beauty of
using a DBMS is to take care of all of that. Unless you're doing some
kind of serious database recovery, I'd say you're better of leaving the
/data directory alone and let PostgreSQL handle that for you. My
admittedly inexperienced opinion is that I'm much more likely to do
serious damage to the system trying to back up individual files rather
than the database (or database cluster) as a whole. And for moving an
database between PostgreSQL installations or backup, I'd use the
pg_dump/pg_restore commands, which are used with a running postmaster.

That said, I have heard of people shutting down the postmaster and
using cp to copy the whole directory.

Sorry if this comes off a little strong. I don't mean to imply your
questions are stupid. It comes from having more trust in PostgreSQL
(and its developers) to handle these things than anyone other than a
very experienced PostgreSQL DBA to mess with anything in the /data
directory. And for what you've described, I think there are safer, more
reliable methods available.

Michael Glaesemann
grzm myrealbox com


pgsql-novice by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: mysql_field_name equivalent
Next
From: Olaf Ferger
Date:
Subject: output of vacuumdb after upgrade to 7.4.1