Moving Database Directory - Mailing list pgsql-admin

From Greg Spiegelberg
Subject Moving Database Directory
Date
Msg-id 3FB3FC17.7020602@cranel.com
Whole thread Raw
Responses Re: Moving Database Directory
List pgsql-admin
Hiya,

I have an interesting problem and haven't found an answer yet on
Google.

On systemA we have a LUN from our SAN mounted as /data and one instance
of 7.3.4 with many databases.  Each database has it's own PGDATA
directory: /data/dbA1 for dbA1 database. /data/dbA2 for dbA2 and so on.
The default PGDATA for systemA, which pg_hba.conf, template0, etc lives
is /data/systemA.

Via Sistina GFS systemB has the same LUN mounted as /data, runs it's own
7.3.4 database with using /data/systemB for pg_hba.conf, template0, etc
and has databases dbB1 and dbB2 under /data/dbB1 and /data/dbB2
respectively.

This works.  Sistina GFS manages block allocation and everything so the
systems don't see anything out of the ordinary.

Here's the curveball / question.

Is there a way to "deport" a database on systemA and "import" it on
systemB without having to do a pg_dump/pg_restore?  Basically ask
the database on systemA to stop using dbA1 under /data/dbA1 then tell
systemB to use the database already at /data/dbA1.

I know I could take postgres down completely on systemA and start it
up on systemB but that would migrate all databases, I want to do only
one, and effectively cut my resources in half on systemB.

I figure the answer will be "no" due to OID number issues, but what say
you Admins?

While I'm here, anyone have experience with Sistina GFS?  This is
completely theoretical right now and we're looking at Sistina GFS to
consolidate our storage and make better use of the space we have.

TIA,
Greg

--
Greg Spiegelberg
  Sr. Product Development Engineer
  Cranel, Incorporated.
  Phone: 614.318.4314
  Fax:   614.431.8388
  Email: gspiegelberg@Cranel.com
Cranel. Technology. Integrity. Focus.



pgsql-admin by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: dropped users appear as numbers in ACL
Next
From: ow
Date:
Subject: pg_restore and FK constraints with large dbs