Re: Postgres Backup Utility - Mailing list pgsql-admin

From French, Martin
Subject Re: Postgres Backup Utility
Date
Msg-id 81976671721DF04B9DCA6ECD87941A40264B2BB5@roundway.Cromwell-tools.co.uk
Whole thread Raw
In response to Postgres Backup Utility  ("Bradley Holbrook" <operations_bradley@servillian.ca>)
Responses Re: Postgres Backup Utility
Re: Postgres Backup Utility
List pgsql-admin
Having been a C/C++ developer many years before being a DBA, and having
written ITIL software; How is migrating structure from a Development
database to a test database whilst maintaining test data backwards?

Besides, the OP was asking how to diff to databases and create ddl, not
asking for us to comment on why he's doing it. Personally, I'd rather
not go trawling through what can only be described as hundreds of
thousands of lines of PostgreSQL log to find THE RIGHT DDL statements.
To me that's surely a recipe for disaster, and certainly not a role I
would expect to complete as a DBA. Yes the Developers should've kept the
DDL for the changes, however; I know from experience that this isn't
always the case, and have found it necessary to "Diff" databases on a
regular basis for one reason or another.

Each time I've done something like this I have resulted to coding shell
scripts, or C programs that are bespoke to accomplish this, as I've yet
to find a tool that does this to my satisfaction levels.

-----Original Message-----
From: Scott Marlowe [mailto:scott.marlowe@gmail.com]
Sent: 20 January 2011 04:41
To: French, Martin
Cc: Bradley Holbrook; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Postgres Backup Utility

On Wed, Jan 19, 2011 at 12:12 AM, French, Martin
<frenchm@cromwell.co.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.

___________________________________________________

This email is intended for the named recipient. The information contained
in it is confidential.  You should not copy it for any purposes, nor
disclose its contents to any other party.  If you received this email
in error, please notify the sender immediately via email, and delete it from
your computer.

Any views or opinions presented are solely those of the author and do not
necessarily represent those of the company.

PCI Compliancy: Please note, we do not send or wish to receive banking, credit
or debit card information by email or any other form of communication.

Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive
Wigston, Leicester LE18 1AT. Tel 0116 2888000
Registered in England and Wales, Reg No 00986161
VAT GB 115 5713 87 900
__________________________________________________


pgsql-admin by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Postgres Backup Utility
Next
From: Scott Marlowe
Date:
Subject: Re: Postgres Backup Utility