      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."

Tue, 27 Jul 2004 14:33:16 +0530
chinni <naveen.bysani@gmail.com>
why is postgres-R not in standard dev Path.
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 
> ?


Tue, 27 Jul 2004 04:10:34 -0500
Thomas F.O'Connell <tfo@sitening.com>
Re: why is postgres-R not in standard dev Path.
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

Tue, 27 Jul 2004 10:37:13 -0400
Chris Browne <cbbrowne@acm.org>
Re: why is postgres-R not in standard dev Path.
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

Tue, 27 Jul 2004 11:03:46 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: why is postgres-R not in standard dev Path. 
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, Pennsylvania 19073

Mon, 2 Aug 2004 04:42:43 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: why is postgres-R not in standard dev Path.