Swapping volumes under tablespaces: supported? - Mailing list pgsql-general

From Kenneth Tilton
Subject Swapping volumes under tablespaces: supported?
Date
Msg-id CAECCA8ZzkfkbX==GBNoVQfKj8wx8kpT-dd7i3DEj=vnHe0rgTw@mail.gmail.com
Whole thread Raw
Responses Re: Swapping volumes under tablespaces: supported?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Currently we refresh our test DB instance by cloning the single production
EC2 volume we use for our entire PG environment and attaching it to the dev
EC2 instance running Postgres. This works well.

But now we are about to add a large quantity of largely static data to our
database. To avoid cloning the static data every time we refresh test
(several times a day), we want to put the new data in its own tablespace
pointing to a different volume, then clone only the default volume to which
the Postgres and default spaces point.

Is that supported?

What if we wanted to replace just the static data? In this case the
unchanged volume would contain the Postgres metadata and we would be
swapping in only the static data volume. Given the important constraint
that nothing can have changed in re the metadata, would that be supported?

My concern is that Postgres might have some internal checksum or something
that would detect our volume swapping and complain on principle. As long as
we are meticulous about not changing the metadata* in the Postgres internal
DBs between volume-swaps, will PG play along?

 * When we do make metadata changes we'll take the hit and clone everything.

--
Kenneth Tilton

*Director of Software Development*

*MCNA Dental Plans*
200 West Cypress Creek Road
Suite 500
Fort Lauderdale, FL 33309

954-730-7131 X181 (Office)
954-628-3347 (Fax)
1-800-494-6262 X181 (Toll Free)

ktilton@mcna.net <glipari@mcna.net> (Email)

www.mcna.net (Website)
CONFIDENTIALITY NOTICE: This electronic mail may contain information that
is privileged, confidential, and/or otherwise protected from disclosure to
anyone other than its intended recipient(s). Any dissemination or use of
this electronic mail or its contents by persons other than the intended
recipient(s) is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by reply
e-mail so that we may correct our internal records. Please then delete the
original message. Thank you.

pgsql-general by date:

Previous
From: AI Rumman
Date:
Subject: no implicit cast error in 9.2?
Next
From: Jay McGaffigan
Date:
Subject: Restoring a database dump from 9.0 to 9.2