Thread: why is postgres-R not in standard dev Path.

why is postgres-R not in standard dev Path.

From
chinni
Date:
      Postgres-R is a multi server (write anywhere) replication tool
which is possibly important for any enterprise if they want to shift
to postgres.

Did you guys debate on merging it.

As of now They are working on postgres 7.2 and developing postgres-R.
They plan to do it for 7.4 as well, why not merge these things.

Is the postgres team planing to come up with a similar tool themselves ?
    

-- 
"Stand for something, or you will fall for nothing."


Re: why is postgres-R not in standard dev Path.

From
Thomas F.O'Connell
Date:
See http://www.slony.org/

It's a master-multislave replication system that has a pretty robust 
development cycle. It just reached a 1.0 release.

Whether any solution becomes a core part of the distribution remains, I 
think, to be seen.

-tfo

On Jul 27, 2004, at 4:03 AM, chinni wrote:

>       Postgres-R is a multi server (write anywhere) replication tool
> which is possibly important for any enterprise if they want to shift
> to postgres.
>
> Did you guys debate on merging it.
>
> As of now They are working on postgres 7.2 and developing postgres-R.
> They plan to do it for 7.4 as well, why not merge these things.
>
> Is the postgres team planing to come up with a similar tool themselves 
> ?



Re: why is postgres-R not in standard dev Path.

From
Tom Lane
Date:
chinni <naveen.bysani@gmail.com> writes:
> Did you guys debate on merging it.

Yes.

If it were actually synced with our current CVS and potentially
mergeable, the debate might have been longer :-(.  But in point of fact,
postgres-R has never been less than two releases behind in the past five
years, and so there was never a time when merging it was technically
feasible.

There are also political issues --- merging it into our core would be
seen as blessing one particular replication solution to the exclusion
of others.

And last I checked, there were licensing issues, because postgres-R
depends on a group-communication package that doesn't use a BSD-style
license.

I'd personally be willing to override the political objections if the
other two categories of problems were surmounted.  But I doubt they
ever will be.
        regards, tom lane


Re: why is postgres-R not in standard dev Path.

From
Chris Browne
Date:
naveen.bysani@gmail.com (chinni) writes:
>       Postgres-R is a multi server (write anywhere) replication tool
> which is possibly important for any enterprise if they want to shift
> to postgres.
>
> Did you guys debate on merging it.

I seem to recall there being a licensing issue; Postgres-R uses the
"Spread" communications toolkit that is distributed under a license
reasonably dissimilar to that of PostgreSQL proper.

> As of now They are working on postgres 7.2 and developing
> postgres-R.  They plan to do it for 7.4 as well, why not merge these
> things.

Why merge them when the development efforts evidently aren't
integrated?  If they were to be merged, this would force the
Postgres-R developers to dance to the PostgreSQL "core team" drum and
vice-versa in order for there to be releases of PostgreSQL.

> Is the postgres team planing to come up with a similar tool
> themselves ?

You might want to look into Slony-I, which is the "first phase" of a
set of replication software.  It has not been concluded that Slony-I
will be included in PostgreSQL proper for some of the same reasons
other replication systems have not been integrated in.

Perhaps come 7.6, usage of Slony-I may become so ubiquitous that
everyone will conclude that it's wisest to integrate it in with the
PostgreSQL code base, but that is certainly not known to be true at
this point in time.

Alternatively, it would probably be even more attractive if, come 7.6,
some set of infrastructure analagous to that associated with the
"contrib" modules could allow easy inclusion of projects managed at
GBorg so that it would be easy for people building BSD Ports, Debian
Packages, and such to draw in "modules" alongside PostgreSQL.  If that
be the case, then it would make sense to drop all sorts of stuff OUT
of the "core" PostgreSQL sources, as it would be easier to manage them
separately...
-- 
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://www.ntlug.org/~cbbrowne/lsf.html
It is impossible to sharpen a  pencil with a blunt axe.  It is equally
vain to try to do it with ten blunt axes instead.
-- Edsger W. Dijkstra


Re: why is postgres-R not in standard dev Path.

From
Bruce Momjian
Date:
Chris Browne wrote:
> naveen.bysani@gmail.com (chinni) writes:
> >       Postgres-R is a multi server (write anywhere) replication tool
> > which is possibly important for any enterprise if they want to shift
> > to postgres.
> >
> > Did you guys debate on merging it.
> 
> I seem to recall there being a licensing issue; Postgres-R uses the
> "Spread" communications toolkit that is distributed under a license
> reasonably dissimilar to that of PostgreSQL proper.

We can get a waver on that license.  I talked to the Spread folks a few
years ago and they were fine with that.  I said we could do the
advertizing better than trying to get the individual users to mention it
somewhere.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073