On Tue, Apr 12, 2016 at 10:14 AM, John R Pierce <pierce@hogranch.com> wrote:
On 4/12/2016 7:55 AM, John McKown wrote:
Hum, I don't know exactly how to do it, but on Linux, you could put the "Customer" database in a tablespace which resides on a BTRFS filesystem. BTRFS can do a quick "snapshot" of the filesystem....
except, tablespaces aren't standalone, and there's no provision for importing the contents of the tablespace. all the metadata remains in the default tablespace, which leaves all sorts of room for problems if you do this.
the /best/ way to achieve what the OP is asking for would likely be to run the tests on a seperate server (or at least seperate postgres instance aka cluster), and use pg_basebackup to rebuild this test instance.
Good point. The reference, http://www.cybertec.at/2015/01/forking-databases-the-art-of-copying-without-copying/ , actually uses btrfs to make a copy using btrfs facilities, which is then used in a _different_ PostgreSQL server instance on the same machine. Actually, the data base _name_ would stay "Customer", but would reside in a separate PostgreSQL server's PGDATA area instead of the production server's PGDATA. Basically, any productions program or scripts could be used, as is, with the test data simply by using the test server's port or unix socket instead of the production server's. Not quite as good as being on a separate Linux image, but not too shabby either. IMO.
-- john r pierce, recycling bits in santa cruz
--
How many surrealists does it take to screw in a lightbulb? One to hold the griffon and one to fill the bathtub with brightly colored LEDs.