Re: Big Test Environment Feature - Mailing list pgsql-hackers

From Bill Cunningham
Subject Re: Big Test Environment Feature
Date
Msg-id 3D0A54E3.2080409@ballydev.com
Whole thread Raw
In response to Big Test Environment Feature  (Matthew Tedder <matthew@tedder.com>)
Responses Re: Big Test Environment Feature  (Matthew Tedder <matthew@tedder.com>)
List pgsql-hackers
Matthew Tedder wrote:

>Question:
>
>    How feasible would it be to create this functionality in PostgreSQL:
>
>One creates a test version of a database that initially consists of 
>read-links to the production version of the same database.  Any code he/she 
>then writes that reads from a table reads from the production database but 
>any code that modifies data copies that table to the test database.
>
>The benefits of this are obviously huge for IT shops that need to constantly 
>work on data in test environments as similar as possible to the production 
>environment.  
>
>Usually, this is a very difficult aspect of one's work and represents a great 
>deal of risk.   We always try to hard to ensure that what we migrate into 
>production is going to work there the same as it did in test.  And we should 
>not do testing in a production environment.
>
>Such a feature would give PostgreSQL a major advantage over Oracle or DB2.
>
>And some day when PostgreSQL is also distributable, it'll be ideal for the 
>enterprise.  
>
>Matthew
>
>  
>

Why wouldn't you use a pg_dump of the production database? Perhaps just 
a sampling every so often?

This sounds like a lot of unnecessary work for the engine. How about a 
seperate program which has
notify links to the source database and places updated data in the test db?

- Bill




pgsql-hackers by date:

Previous
From: Mike Mascari
Date:
Subject: Re: Non-standard feature request
Next
From: Bruno Wolff III
Date:
Subject: Re: FEATURE REQUEST - More dynamic date type?