Re: Postgres Backup Utility

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: "French, Martin" <frenchm(at)cromwell(dot)co(dot)uk>
Cc: Bradley Holbrook <operations_bradley(at)servillian(dot)ca>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Postgres Backup Utility
Date: 2011-01-20 04:40:58
Message-ID: AANLkTi=E0EjWKUuxiOyOOmemKYga9Z=5a4iJbsbKX=hE@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Wed, Jan 19, 2011 at 12:12 AM, French, Martin <frenchm(at)cromwell(dot)co(dot)uk> wrote:
> Ok, you say that you cannot drop and recreate, so you need to do this via
> alter statements only? That’s obviously going to complicate matters, as a
> straight dump, drop, recreate, restore would be the fastest and by far
> simplest method.
>
>
>
> So, Ideally, you’ll need to do a table def comparison over the two
> databases, and generate the necessary sql to amend the tables in test
> accordingly?

Sorry but this is exactly backwards from good procedure. What you do
it have your developers checkin the SQL code they used to alter the
tables / add rows in the test database, and you apply that to testing
/ QA / staging / production. Any other way is a recipe for both
disaster and DBA burnout.

To make it easier, you can always turn on ddl logging on the
developer's databases and then just trawl the logs for what they did.
Still easier than trying to compare schemas and figure out what's
different and how to write the SQL to make it happen.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message French, Martin 2011-01-20 12:00:47 Re: Postgres Backup Utility
Previous Message Kevin Grittner 2011-01-20 00:29:38 Re: Posting PostgresqL Job Opportunity