From: | "Aaron Bono" <postgresql(at)aranya(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Infor Gates" <info_gates(at)yahoo(dot)com>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: pg_restore |
Date: | 2006-06-18 21:29:57 |
Message-ID: | bf05e51c0606181429j75cfa4a9qdb7654d2b9b85d2c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
I agree. When restoring a database from back up, I do a drop database and
recreate it to make sure everything is properly intact (tables, columns,
views, triggers, foreign keys, etc...). We do this a lot for testing. We
backup the production database, copy to test server and do a restore on the
test database. It helps us test our code rollouts.
-Aaron
On 6/18/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Infor Gates <info_gates(at)yahoo(dot)com> writes:
> > I am having the impression that pg_restore would over-rides the "old"
> > data with the current one. Is my thinking wrong?
>
> Yeah. By default, pg_restore will issue a CREATE TABLE (which of course
> fails if the table already exists) followed by COPY (which just tries to
> insert data in addition to what might be there already).
>
> There's a command line option to ask pg_restore to try to DROP TABLE
> before doing the CREATE TABLE. By and large, though, that's a bad way
> to proceed unless you are specifically trying to merge two databases.
> The fast and easy way to proceed is to DROP DATABASE, CREATE a fresh
> empty database, and pg_restore into that.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Infor Gates | 2006-06-19 01:02:50 | Re: pg_restore |
Previous Message | Ravindra Guravannavar | 2006-06-18 08:45:57 | clustering takes too long! |