Re: pg_restore - Mailing list pgsql-admin

From Aaron Bono
Subject Re: pg_restore
Date
Msg-id bf05e51c0606181429j75cfa4a9qdb7654d2b9b85d2c@mail.gmail.com
Whole thread Raw
In response to Re: pg_restore  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_restore  (Infor Gates <info_gates@yahoo.com>)
List 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@sss.pgh.pa.us> wrote:
Infor Gates <info_gates@yahoo.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

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_restore
Next
From: Infor Gates
Date:
Subject: Re: pg_restore