Re: Replicating databases - Mailing list pgsql-general

From Christopher Browne
Subject Re: Replicating databases
Date
Msg-id m3y8447z0x.fsf@mobile.int.cbbrowne.com
Whole thread Raw
In response to Re: Replicating databases  (Marc Munro <marc@bloodnok.com>)
List pgsql-general
>> But if someone decided to "fork" their own *new* project, perhaps
>> starting based on one of the releases, that would an entirely
>> interesting idea.
>
> Wouldn't async multimaster make use of most all of what slony-I
> currently has? ISTM that it would make life a lot easier to use one
> combined project rather than two...

When you combine projects, you require the participants to participate
in the union of the complexity of the projects.  The project can't
generate releases unless they all coordinate a release, and if their
interests differ, that can be tough to do...  There are OSes we could
name where increasing sets of participants are having that very
effect...

If projects remain largely independent, they can limit themselves to
their respective individual sets of complexities.  That's precisely
why the PostgreSQL project is trying to push as many of the "contrib"
things out to outside projects as possible.

There's a famous saying about "sufficient to the day is the evil
thereof;" we might substitute "project" for "day" in that ;-).
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://linuxfinances.info/info/wp.html
"Whenever you  find that you  are on the  side of the majority,  it is
time to reform." -- Mark Twain

pgsql-general by date:

Previous
From: David Gagnon
Date:
Subject: Re: pl/pgsql list as parameter.
Next
From: Marc Boucher
Date:
Subject: Re: Changing ids conflicting with serial values?