Re: CLONE DATABASE (with copy on write?)

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: "Clark C(dot) Evans" <cce(at)clarkevans(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: CLONE DATABASE (with copy on write?)
Date: 2011-11-13 07:33:44
Message-ID: CA+U5nMJ_srUrSfo7K=D8Fv3hAEF=fc20W2_XWR1tyQFabM3_Xg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Nov 12, 2011 at 9:40 PM, Clark C. Evans <cce(at)clarkevans(dot)com> wrote:

> Our company has some headaches in our application development
> and deployment process.  The chief problem is, "creating stages",
> which to this audience is, cloning a database efficiently,
> making and testing a few changes, perhaps recording the
> differences between databases, and then dropping the database.
>
> I'm eternally grateful for someone who pointed out that we
> should be using "CREATE DATABASE ... WITH TEMPLATE".  However,
> this has two big disadvantages.  First, it only works if you
> can kick the users off the clone.  Secondly, it still takes
> time, uses disk space, etc.  We have some big databases.

An interesting proposal. Thanks for taking the time to raise this.

The existing situation is that you need to either

1) quiesce the database so it can be copied locally

2) take a hot backup to create a clone on another server

(1) currently involves disconnection. Would a command to quiesce
sessions without disconnection be useful? We could get sessions to
sleep until woken after the copy. With large databases we would still
need to copy while sessions sleep to ensure a consistent database
after the copy.

Is (2) a problem for you? In what way?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2011-11-13 09:31:22 Re: Error with Application Stack Builder 3.0.0
Previous Message Simon Riggs 2011-11-13 07:14:28 Re: Large values for duration of COMMITs and slow queries. Due to large WAL config values?