> On Apr 12, 2016, at 11:14 AM, John R Pierce <pie...@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.
>
>
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
I agree with John’s post. I should have mentioned that my template database is
never production. It’s an obfuscated copy of the production data on separate
hardware. I use the "create with template” to spin up copies for
developers/testers to provide a representative data set (not identical to
production). And, since the create doesn’t copy table statistics, I have to
kick off a post-copy background process to gather them:
nohup vacuumdb --analyze-only --quiet --dbname=${DATABASE} &>/dev/null &
Still, with all that, users are still able to drop and recreate a test database
within a coffee break.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
