Re: RFC tool to support development / operations work with slony replicated databases

From: Mark Stosberg <mark(at)summersault(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: slony1-general(at)gborg(dot)postgresql(dot)org
Subject: Re: RFC tool to support development / operations work with slony replicated databases
Date: 2007-03-08 15:50:08
Message-ID: espbcg$ads$1@sea.gmane.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Andrew Hammond wrote:
> Hello All,
>
> I've been working on designing a tool to facilitate both developers
> and operations staff working with slony replicated databases. I think
> that the problem described below is a general problem for people
> working with systems that are both in production and under on-going
> development / maintenance. As a result I would like to both solicit
> the input of the community and share the results. Documentation (which
> is still somewhat drafty) follows.

Andrew,

I think this is a useful idea, that I would be interested in trying myself.

One suggestion: It would be great if there was an option for the
"downgrade" path to be determined automatically, or ignored as option.
I think in some scenarios, it's just not very practical to "go back"
without restoring from a dump file of the old state.

Perhaps there could be some integration with a "diff" tool like APG?

http://pgfoundry.org/projects/apgdiff

Given two databases schemas, it could generate /both/ upgrade and
downgrade paths.

That would work for some simple cases, and manual changes could be used
for more complex cases, which as were data needs to be changed and
changed back as part of an upgrade/downgrade.

Thanks again for your work on this tool!

Mark

In response to

Browse pgsql-general by date

  From Date Subject
Next Message John Gateley 2007-03-08 15:53:10 Re: Database deadlock/hanging
Previous Message Reuven M. Lerner 2007-03-08 15:43:47 Re: Database slowness -- my design, hardware, or both?