Thread: Update on replication

Update on replication

From
Bruce Momjian
Date:
Update on replication:

We have several things happening with Postgres-R replication:
o  Someone is porting the 7.2-based Postgres-R code to 7.3o  Darren and I are in discussion with the Spread folks,
attemptingto get a more BSD-friendly license from themo  People are evaluating the Postgres-R approach and comparing
itto more traditional 2-phase commit replication.
 

With these things moving forward, we will be in a much better position
to get synchronous replication integrated in PostgreSQL.

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


Re: Update on replication

From
Rod Taylor
Date:
>     o  People are evaluating the Postgres-R approach and comparing
>        it to more traditional 2-phase commit replication.

Not that the Postgres-R approach can replace 2-phase commit methods.

2PC is still needed for support with external transaction managers (XA
drivers for JDBC).

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

Re: Update on replication

From
Bruce Momjian
Date:
Rod Taylor wrote:
-- Start of PGP signed section.
> >     o  People are evaluating the Postgres-R approach and comparing
> >        it to more traditional 2-phase commit replication.
> 
> Not that the Postgres-R approach can replace 2-phase commit methods.
> 
> 2PC is still needed for support with external transaction managers (XA
> drivers for JDBC).

Yes, good point.  Let me add that eventually, I think we will have:
sync replication (Postgres-R?)async replication, using PITRPITRtwo-phase commit for distributed transactions

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


Re: Update on replication

From
Alvaro Herrera
Date:
On Tue, Dec 17, 2002 at 12:56:45PM -0500, Bruce Momjian wrote:
> Update on replication:
> 
> We have several things happening with Postgres-R replication:
> 
>     o  Someone is porting the 7.2-based Postgres-R code to 7.3

You mean 7.4devel?

> With these things moving forward, we will be in a much better position
> to get synchronous replication integrated in PostgreSQL.

What about asynchronous (triggered?) replication?  Is something like
rserv or dbmirror going to be moved to main?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?"  (Mafalda)


Re: Update on replication

From
Bruce Momjian
Date:
Alvaro Herrera wrote:
> On Tue, Dec 17, 2002 at 12:56:45PM -0500, Bruce Momjian wrote:
> > Update on replication:
> > 
> > We have several things happening with Postgres-R replication:
> > 
> >     o  Someone is porting the 7.2-based Postgres-R code to 7.3
> 
> You mean 7.4devel?

Sorry, right.

> > With these things moving forward, we will be in a much better position
> > to get synchronous replication integrated in PostgreSQL.
> 
> What about asynchronous (triggered?) replication?  Is something like
> rserv or dbmirror going to be moved to main?

I think eventually we will have some async replication in the main
server, probably using PITR logs in some way.

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


Re: Update on replication

From
"Roderick A. Anderson"
Date:
I just got my copy of SysAdmin Magazine and was surprised to see an 
article about Usogres -- The PostgreSQL Replication Tool.

I don't remember seeing it mentioned on this or the General list.  Though
I just started reading the article and don't have a firm grasp on it yet, 
I do remember a discussion of replication using this technique - described 
in the first two paragraphs.


Fyi,
Rod
--  "Open Source Software - Sometimes you get more than you paid for..."



Re: Update on replication

From
Bruce Momjian
Date:
Roderick A. Anderson wrote:
> I just got my copy of SysAdmin Magazine and was surprised to see an 
> article about Usogres -- The PostgreSQL Replication Tool.
> 
> I don't remember seeing it mentioned on this or the General list.  Though
> I just started reading the article and don't have a firm grasp on it yet, 
> I do remember a discussion of replication using this technique - described 
> in the first two paragraphs.

I saw Usogres when I was first in Japan.  Interesting in that is
intercepts queries and passes them two different servers.

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


Re: Update on replication

From
"Marc G. Fournier"
Date:
On Tue, 17 Dec 2002, Alvaro Herrera wrote:

> What about asynchronous (triggered?) replication?  Is something like
> rserv or dbmirror going to be moved to main?

From what I've been able to tell *so far*, Postgres-R is going to preclude
the ability for either to work ... Vadim is currently reviewing the code,
and based on his assessment of whether or not that is the case, I'm going
to be pushing for postgres-r to be its own project/fork of PostgreSQL,
like RedHat Database ...





Re: Update on replication

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Tue, 17 Dec 2002, Alvaro Herrera wrote:
> 
> > What about asynchronous (triggered?) replication?  Is something like
> > rserv or dbmirror going to be moved to main?
> 
> From what I've been able to tell *so far*, Postgres-R is going to preclude
> the ability for either to work ... Vadim is currently reviewing the code,
> and based on his assessment of whether or not that is the case, I'm going
> to be pushing for postgres-r to be its own project/fork of PostgreSQL,
> like RedHat Database ...

How is Postgres-R going to prevent async replication from also being
adopted in CVS?

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


Re: Update on replication

From
"Marc G. Fournier"
Date:
ooops, sorry, that was what I meant (its been one of those days *grin*)


On Tue, 17 Dec 2002, Mikheev, Vadim wrote:

> > From what I've been able to tell *so far*, Postgres-R is
> > going to preclude the ability for either to work ...
> > Vadim is currently reviewing the code,
>
> Not the code, just Darren' pdf ("slide show" -:()
> and discussion in hackers' list.
>
>
> _____________________________________________________
> Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
>


Re: Update on replication

From
Date:

> Not the code, just Darren' pdf ("slide show" -:()
> and discussion in hackers' list.
> 


You might want to read this paper.  Its not very long, and
will give you much more insite on the postgres-r work.

http://www.cs.mcgill.ca/~kemme/papers/vldb00.html

Darren



Re: Update on replication

From
Tom Lane
Date:
"Marc G. Fournier" <scrappy@hub.org> writes:
> On Tue, 17 Dec 2002, Alvaro Herrera wrote:
>> What about asynchronous (triggered?) replication?  Is something like
>> rserv or dbmirror going to be moved to main?

>> From what I've been able to tell *so far*, Postgres-R is going to preclude
> the ability for either to work ...

Why do you say that?  If it can't coexist with other solutions, then it
surely will not be accepted, but I can't think of any reason why it
would preclude other approaches.
        regards, tom lane


Re: Update on replication

From
"Marc G. Fournier"
Date:
On Tue, 17 Dec 2002, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
> > On Tue, 17 Dec 2002, Alvaro Herrera wrote:
> >> What about asynchronous (triggered?) replication?  Is something like
> >> rserv or dbmirror going to be moved to main?
>
> >> From what I've been able to tell *so far*, Postgres-R is going to preclude
> > the ability for either to work ...
>
> Why do you say that?  If it can't coexist with other solutions, then it
> surely will not be accepted, but I can't think of any reason why it
> would preclude other approaches.

Okay, if this is the case, that does change things somewhat, but Bruce
seems to indiate that co-existance will be a problem:


========
> On Tue, 17 Dec 2002, Bruce Momjian wrote:
>
> > > The other concern is how does integrating Postgres-R affect the ability to
> > > investigate other solutions?
> > >
> > > As I said, I don't doubt taht there are aspects of Postgres-R that would
> > > benefit the server as a whole, and those bits-n-pieces should be looked at
> > > on an individual basis, but to just slap it in completely and hope that it
> > > doesn't cause problems for alternative solutions is kinda irresponsible
> > > ...
> >
> > It certainly will cause problems with other replication solutions.


Re: Update on replication

From
Bruce Momjian
Date:
When I said:

> > > It certainly will cause problems with other replication solutions.

I meant it would cause other solutions to be less desirable, meaning. as
you said, "affect the ability to investigate other solutions?"  With a
working solution, others may be less likely to investigate because
Postgres-R will be our official solution.  (I believe that was your
major negative point.)  However, with the hooks already there, people
may be _more_ likely to investigate solutions, so there is really no way
to know.

---------------------------------------------------------------------------

Marc G. Fournier wrote:
> On Tue, 17 Dec 2002, Tom Lane wrote:
> 
> > "Marc G. Fournier" <scrappy@hub.org> writes:
> > > On Tue, 17 Dec 2002, Alvaro Herrera wrote:
> > >> What about asynchronous (triggered?) replication?  Is something like
> > >> rserv or dbmirror going to be moved to main?
> >
> > >> From what I've been able to tell *so far*, Postgres-R is going to preclude
> > > the ability for either to work ...
> >
> > Why do you say that?  If it can't coexist with other solutions, then it
> > surely will not be accepted, but I can't think of any reason why it
> > would preclude other approaches.
> 
> Okay, if this is the case, that does change things somewhat, but Bruce
> seems to indiate that co-existance will be a problem:
> 
> 
> ========
> > On Tue, 17 Dec 2002, Bruce Momjian wrote:
> >
> > > > The other concern is how does integrating Postgres-R affect the ability to
> > > > investigate other solutions?
> > > >
> > > > As I said, I don't doubt taht there are aspects of Postgres-R that would
> > > > benefit the server as a whole, and those bits-n-pieces should be looked at
> > > > on an individual basis, but to just slap it in completely and hope that it
> > > > doesn't cause problems for alternative solutions is kinda irresponsible
> > > > ...
> > >
> > > It certainly will cause problems with other replication solutions.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

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


Re: Update on replication

From
"Marc G. Fournier"
Date:
On Tue, 17 Dec 2002, Bruce Momjian wrote:

> I meant it would cause other solutions to be less desirable, meaning. as
> you said, "affect the ability to investigate other solutions?"  With a
> working solution, others may be less likely to investigate because
> Postgres-R will be our official solution.  (I believe that was your
> major negative point.)  However, with the hooks already there, people
> may be _more_ likely to investigate solutions, so there is really no way
> to know.

Okay, but if we are just adding hooks to allow Postgres-R to tie in, can't
those hooks be done in such a way as to be loadable, not compiled in?


Re: Update on replication

From
Tatsuo Ishii
Date:
> Marc G. Fournier wrote:
> > On Tue, 17 Dec 2002, Alvaro Herrera wrote:
> > 
> > > What about asynchronous (triggered?) replication?  Is something like
> > > rserv or dbmirror going to be moved to main?
> > 
> > From what I've been able to tell *so far*, Postgres-R is going to preclude
> > the ability for either to work ... Vadim is currently reviewing the code,
> > and based on his assessment of whether or not that is the case, I'm going
> > to be pushing for postgres-r to be its own project/fork of PostgreSQL,
> > like RedHat Database ...
> 
> How is Postgres-R going to prevent async replication from also being
> adopted in CVS?

As far as I know, all trigger based async replication solutions have a
limitation. They do not handle high load (and probably cannot handle
large objects. am I correct?). I think we should move to other async
replication soltions, such as PostgreSQL-R or (not yet existing)
transaction log based replications.
--
Tatsuo Ishii


Re: Update on replication

From
Tatsuo Ishii
Date:
> I just got my copy of SysAdmin Magazine and was surprised to see an 
> article about Usogres -- The PostgreSQL Replication Tool.
> 
> I don't remember seeing it mentioned on this or the General list.  Though
> I just started reading the article and don't have a firm grasp on it yet, 
> I do remember a discussion of replication using this technique - described 
> in the first two paragraphs.

Glad to hear that. Usogres was developed in Japan and pretty popular
ammong Japanese PostgreSQL community.

BTW, there is a commercial product called QueryMaster, which takes
similar approach to Usogres. It copies the input query and distribute
to multiple PostgreSQL servers. As long as one of a server is working,
users even do not notice some of them are failing.
--
Tatsuo Ishii


Re: Update on replication

From
"Marc G. Fournier"
Date:
On Wed, 18 Dec 2002, Tatsuo Ishii wrote:

> > I just got my copy of SysAdmin Magazine and was surprised to see an
> > article about Usogres -- The PostgreSQL Replication Tool.
> >
> > I don't remember seeing it mentioned on this or the General list.  Though
> > I just started reading the article and don't have a firm grasp on it yet,
> > I do remember a discussion of replication using this technique - described
> > in the first two paragraphs.
>
> Glad to hear that. Usogres was developed in Japan and pretty popular
> ammong Japanese PostgreSQL community.
>
> BTW, there is a commercial product called QueryMaster, which takes
> similar approach to Usogres. It copies the input query and distribute
> to multiple PostgreSQL servers. As long as one of a server is working,
> users even do not notice some of them are failing.

How come these solutions are such well kept secrets?  I've heard of
neither in relation to past discussions about replication, or have I just
missed them? :(



Re: Update on replication

From
Greg Copeland
Date:
On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote:
> On Wed, 18 Dec 2002, Tatsuo Ishii wrote:
> 
> > > I just got my copy of SysAdmin Magazine and was surprised to see an
> > > article about Usogres -- The PostgreSQL Replication Tool.
> > >
> > > I don't remember seeing it mentioned on this or the General list.  Though
> > > I just started reading the article and don't have a firm grasp on it yet,
> > > I do remember a discussion of replication using this technique - described
> > > in the first two paragraphs.
> >
> > Glad to hear that. Usogres was developed in Japan and pretty popular
> > ammong Japanese PostgreSQL community.
> >
> > BTW, there is a commercial product called QueryMaster, which takes
> > similar approach to Usogres. It copies the input query and distribute
> > to multiple PostgreSQL servers. As long as one of a server is working,
> > users even do not notice some of them are failing.
> 
> How come these solutions are such well kept secrets?  I've heard of
> neither in relation to past discussions about replication, or have I just
> missed them? :(
> 

Good questions.  I've heard of Usogres, more or less in passing, but
heard it didn't work very well.  Also heard that it wasn't reliable or a
serious solution.  I seem to remember hearing that it only worked on
much older versions of PostgreSQL.  Of course, I'm not attempting to
assert any true to what I've heard but since it's being talking about,
perhaps someone can clarify how well it REALLY works.  Perhaps even
provide some more details on it?

Never heard of QueryMaster.  Perhaps someone would like to talk a little
more about that as well?




-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting



Re: Update on replication

From
"Marc G. Fournier"
Date:
On Tue, 17 Dec 2002, Greg Copeland wrote:

> On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote:
> > On Wed, 18 Dec 2002, Tatsuo Ishii wrote:
> >
> > > > I just got my copy of SysAdmin Magazine and was surprised to see an
> > > > article about Usogres -- The PostgreSQL Replication Tool.
> > > >
> > > > I don't remember seeing it mentioned on this or the General list.  Though
> > > > I just started reading the article and don't have a firm grasp on it yet,
> > > > I do remember a discussion of replication using this technique - described
> > > > in the first two paragraphs.
> > >
> > > Glad to hear that. Usogres was developed in Japan and pretty popular
> > > ammong Japanese PostgreSQL community.
> > >
> > > BTW, there is a commercial product called QueryMaster, which takes
> > > similar approach to Usogres. It copies the input query and distribute
> > > to multiple PostgreSQL servers. As long as one of a server is working,
> > > users even do not notice some of them are failing.
> >
> > How come these solutions are such well kept secrets?  I've heard of
> > neither in relation to past discussions about replication, or have I just
> > missed them? :(
> >
>
> Good questions.  I've heard of Usogres, more or less in passing, but
> heard it didn't work very well.  Also heard that it wasn't reliable or a
> serious solution.  I seem to remember hearing that it only worked on
> much older versions of PostgreSQL.  Of course, I'm not attempting to
> assert any true to what I've heard but since it's being talking about,
> perhaps someone can clarify how well it REALLY works.  Perhaps even
> provide some more details on it?
>
> Never heard of QueryMaster.  Perhaps someone would like to talk a little
> more about that as well?

Just checked on Usogres, and it appears to be relatively up to date, in
that it is known to work up to 7.2.1:
    http://usogres.good-day.net/working.php3

Searching Google for QueryMaster finds a few Japanese sites, but I can't
read Japanese :(

Tatsuo, can you help?


Re: Update on replication

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> Just checked on Usogres, and it appears to be relatively up to date, in
> that it is known to work up to 7.2.1:
> 
>         http://usogres.good-day.net/working.php3
> 
> Searching Google for QueryMaster finds a few Japanese sites, but I can't
> read Japanese :(
> 
> Tatsuo, can you help?

Use Altavista:
http://world.altavista.com/

They have a Japense/English translation.

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


Re: Update on replication

From
Tatsuo Ishii
Date:
> > Glad to hear that. Usogres was developed in Japan and pretty popular
> > ammong Japanese PostgreSQL community.
> >
> > BTW, there is a commercial product called QueryMaster, which takes
> > similar approach to Usogres. It copies the input query and distribute
> > to multiple PostgreSQL servers. As long as one of a server is working,
> > users even do not notice some of them are failing.
> 
> How come these solutions are such well kept secrets?  I've heard of
> neither in relation to past discussions about replication, or have I just
> missed them? :(

As far as I can remember, Usogres has appeared on this list for
several times.

About QueryMaster: it is born in US and is a fairly new
product. Unfortunately I couldn't find web pages for it. I'll talk to
a person who is selling it in Japan if he could provide info in
English...
--
Tatsuo Ishii


Re: Update on replication

From
Alvaro Herrera
Date:
On Tue, Dec 17, 2002 at 07:43:05PM -0600, Greg Copeland wrote:
> On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote:

> > How come these solutions are such well kept secrets?  I've heard of
> > neither in relation to past discussions about replication, or have I just
> > missed them? :(
> 
> Good questions.  I've heard of Usogres, more or less in passing, but
> heard it didn't work very well.

I'm sure this is because there little or no documentation of the system
in english.  I tried Usogres sometime ago, and felt really lost.  I
managed to install it and maybe even got it to work, but the
documentation was so lacking that I didn't feel confident enough with
it.

I think the same can be said of QueryMaster, plus it isn't mentioned
anywhere.  How can I possibly search for documentation on a project if I
don't know it even exists?

One would be tempted to say that GBorg is a good place to list
PostgreSQL related projects.  Sadly, GBorg doesn't even have a
connection to the outside world.  What value does it have if people
don't know it exists, or can't remember how to get to it?  Let alone use
it to find a project...

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Now I have my system running, not a byte was off the shelf;
It rarely breaks and when it does I fix the code myself.
It's stable, clean and elegant, and lightning fast as well,
And it doesn't cost a nickel, so Bill Gates can go to hell."


Re: Update on replication

From
"Marc G. Fournier"
Date:
On Wed, 18 Dec 2002, Tatsuo Ishii wrote:

> > > Glad to hear that. Usogres was developed in Japan and pretty popular
> > > ammong Japanese PostgreSQL community.
> > >
> > > BTW, there is a commercial product called QueryMaster, which takes
> > > similar approach to Usogres. It copies the input query and distribute
> > > to multiple PostgreSQL servers. As long as one of a server is working,
> > > users even do not notice some of them are failing.
> >
> > How come these solutions are such well kept secrets?  I've heard of
> > neither in relation to past discussions about replication, or have I just
> > missed them? :(
>
> As far as I can remember, Usogres has appeared on this list for
> several times.
>
> About QueryMaster: it is born in US and is a fairly new
> product. Unfortunately I couldn't find web pages for it. I'll talk to
> a person who is selling it in Japan if he could provide info in
> English...

*rofl*  I like that ... a US product, but all the pdf's and docs I can
find on it are in Japanese ... I think its almost time to learn a third
language :)




Re: Update on replication

From
Greg Copeland
Date:
On Tue, 2002-12-17 at 20:07, Alvaro Herrera wrote:
> On Tue, Dec 17, 2002 at 07:43:05PM -0600, Greg Copeland wrote:
> > On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote:
> 
> > > How come these solutions are such well kept secrets?  I've heard of
> > > neither in relation to past discussions about replication, or have I just
> > > missed them? :(
> > 
> > Good questions.  I've heard of Usogres, more or less in passing, but
> > heard it didn't work very well.
> 
> I'm sure this is because there little or no documentation of the system
> in english.  I tried Usogres sometime ago, and felt really lost.  I
> managed to install it and maybe even got it to work, but the
> documentation was so lacking that I didn't feel confident enough with
> it.
> 
> I think the same can be said of QueryMaster, plus it isn't mentioned
> anywhere.  How can I possibly search for documentation on a project if I
> don't know it even exists?
> 
> One would be tempted to say that GBorg is a good place to list
> PostgreSQL related projects.  Sadly, GBorg doesn't even have a
> connection to the outside world.  What value does it have if people
> don't know it exists, or can't remember how to get to it?  Let alone use
> it to find a project...

There are a couple of links to it from PostgreSQL's site, but you sorta
have to look and hunt around.  I've requested higher visibility but for
whatever reason it seemed to be snubbed rather quickly.

I do agree, GBorg needs MUCH higher visibility!


-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting



Re: Update on replication

From
"Marc G. Fournier"
Date:
On Tue, 17 Dec 2002, Greg Copeland wrote:

> There are a couple of links to it from PostgreSQL's site, but you sorta
> have to look and hunt around.  I've requested higher visibility but for
> whatever reason it seemed to be snubbed rather quickly.
>
> I do agree, GBorg needs MUCH higher visibility!

Dave is pretty much ready to put teh portal in place
(http://wwwdevel.postgresql.org) which has several links to GBorg right
off the main page ...



Re: Update on replication

From
"Christopher Kings-Lynne"
Date:
> There are a couple of links to it from PostgreSQL's site, but you sorta
> have to look and hunt around.  I've requested higher visibility but for
> whatever reason it seemed to be snubbed rather quickly.
>
> I do agree, GBorg needs MUCH higher visibility!

Yes - I would love to move phpPgAdmin back to GBorg to attract some actual
interested developers, but I'm not sure it would...

Chris



Re: Update on replication

From
Neil Conway
Date:
On Tue, 2002-12-17 at 21:33, Greg Copeland wrote:
> I do agree, GBorg needs MUCH higher visibility!

I'm just curious: why do we need GBorg at all? Does it offer anything
that SourceForge, or a similar service does not offer?

Especially given that (a) most other OSS projects don't have a site for
"related projects" (unless you count something like CPAN, which is
totally different) (b) GBorg is completely unknown to anyone outside the
PostgreSQL community and even to many people within it...

Cheers,

Neil
-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC





Re: Update on replication

From
Bruce Momjian
Date:
Neil Conway wrote:
> On Tue, 2002-12-17 at 21:33, Greg Copeland wrote:
> > I do agree, GBorg needs MUCH higher visibility!
> 
> I'm just curious: why do we need GBorg at all? Does it offer anything
> that SourceForge, or a similar service does not offer?
> 
> Especially given that (a) most other OSS projects don't have a site for
> "related projects" (unless you count something like CPAN, which is
> totally different) (b) GBorg is completely unknown to anyone outside the
> PostgreSQL community and even to many people within it...

I think gborg allows us to collect all relivant projects in one place.

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


Re: Update on replication

From
Neil Conway
Date:
On Tue, 2002-12-17 at 22:00, Bruce Momjian wrote:
> I think gborg allows us to collect all relivant projects in one place.

Yes, but so would a webpage with a list of URLs, or a
freshmeat/google/dmoz directory, or an SF foundry, or [ any number of
other mechanisms for collecting groups of related websites ].

(Not to mention that you're assuming that GBorg includes "all relevant
projects" -- it doesn't do that now, nor is it likely to in the future.)

Cheers,

Neil
-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC





Re: Update on replication

From
Greg Copeland
Date:
On Tue, 2002-12-17 at 20:55, Neil Conway wrote:
> On Tue, 2002-12-17 at 21:33, Greg Copeland wrote:
> > I do agree, GBorg needs MUCH higher visibility!
> 
> I'm just curious: why do we need GBorg at all? Does it offer anything
> that SourceForge, or a similar service does not offer?
> 
> Especially given that (a) most other OSS projects don't have a site for
> "related projects" (unless you count something like CPAN, which is
> totally different) (b) GBorg is completely unknown to anyone outside the
> PostgreSQL community and even to many people within it...
> 


Part I can answer, part I can not.  Since I'm not the one that pushed
the projects to that site, I can't answer that part of the equation. 
Addressing the part of your question that I think I can, I do like the
concept of one-stop-shopping for all PostgreSQL needs.  All Things
ProgreSQL is a pretty neat concept.  Of course, it rather defeats the
whole purpose if no one, including potential developers, have no idea it
exists.



-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting



Re: Update on replication

From
Bruce Momjian
Date:
Neil Conway wrote:
> On Tue, 2002-12-17 at 22:00, Bruce Momjian wrote:
> > I think gborg allows us to collect all relivant projects in one place.
> 
> Yes, but so would a webpage with a list of URLs, or a
> freshmeat/google/dmoz directory, or an SF foundry, or [ any number of
> other mechanisms for collecting groups of related websites ].
> 
> (Not to mention that you're assuming that GBorg includes "all relevant
> projects" -- it doesn't do that now, nor is it likely to in the future.)

Good point. I put my stuff on there because it was PostgreSQL-specific,
and it had nice features.

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


Re: [mail] Re: Update on replication

From
"Al Sutton"
Date:
The reason I favour a GBorg is that VA Linux (who own sourceforge) have yet
to turn in a profit and so maylook to trim some of it's assets in order to
improve profitability at some point in the future.

I think it would be a bad move to shift everything to sourceforge, only to
find that a year or more down the line the site dissappears/degrades to a
level where it causes problems for the project, and loose the time we could
have spent building up the reputation of GBorg.

Al.


----- Original Message -----
From: "Neil Conway" <neilc@samurai.com>
To: "Greg Copeland" <greg@CopelandConsulting.Net>
Cc: "Alvaro Herrera" <alvherre@dcc.uchile.cl>; "Marc G. Fournier"
<scrappy@hub.org>; "Tatsuo Ishii" <t-ishii@sra.co.jp>; <raanders@acm.org>;
"PostgresSQL Hackers Mailing List" <pgsql-hackers@postgresql.org>
Sent: Wednesday, December 18, 2002 2:55 AM
Subject: [mail] Re: [HACKERS] Update on replication


> On Tue, 2002-12-17 at 21:33, Greg Copeland wrote:
> > I do agree, GBorg needs MUCH higher visibility!
>
> I'm just curious: why do we need GBorg at all? Does it offer anything
> that SourceForge, or a similar service does not offer?
>
> Especially given that (a) most other OSS projects don't have a site for
> "related projects" (unless you count something like CPAN, which is
> totally different) (b) GBorg is completely unknown to anyone outside the
> PostgreSQL community and even to many people within it...
>
> Cheers,
>
> Neil
> --
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>




SourceForge policy on http://sourceforge.net/tos/tos.php

From
Jean-Michel POURE
Date:
> I'm just curious: why do we need GBorg at all? Does it offer anything
> that SourceForge, or a similar service does not offer?

SAY NO TO SOURCEFORGE !

Please find enclosed some extracts from licensing terms
(http://sourceforge.net/tos/tos.php) :

a) Acceptance of Terms

"We reserve the right, at our discretion, to change, modify, add or remove
portions of these terms periodically. Such modifications shall be effective
immediately upon posting of the modified agreement to the website. Your
continued use of the SourceForge.net website following the posting of changes
to these terms and conditions will mean that you accept those changes."

-> My point of view : SourceForge has an unlimited right to change the content
of the TOS. A simpe post of the modified TOS is sufficient. For example, they
may at any time charge access to their web site.

b) Licensing of code

"In each such case, the submitting user grants SourceForge.net the
royalty-free, perpetual, irrevocable, non-exclusive and fully sublicensable
right and license to use, reproduce, modify, adapt, publish, translate,
create derivative works from, distribute, perform and display such Content
(in whole or part) worldwide and/or to incorporate it in other works in any
form, media, or technology now known or later developed, all subject to the
terms of any applicable approved license."

-> My point of view : More surprisingly, SourceForge owns all content posted
on SourceForge. For legal reasons, SF licensing agreement is subject to the
terms of any applicable approved license. But, the words *** or later
development *** are thrilling.

c) Termination

"We may terminate a user's account in our absolute discretion and for any
reason. We are especially likely to terminate for reasons that include, but
are not limited to, the following: 1.) violation of these Terms; 2.) abuse of
site resources or attempt to gain unauthorized entry to the site or site
resources; 3.) use of Service in a manner inconsistent with the Purpose; 4.)
a user's request for such termination; and 5.) requirement of applicable law,
regulation, court or governing agency order.

-> My point of view : As a consequence, SourceForge does not allow a user to
unregister from SourceForge. I tried to unregister a project from SF, without
success. Why? Because SF owns the (your) project rights.

d) Incompatibility with local european laws

This contract does not comply with the European laws :

- SF may change the licensing terms at any time, without limitation of the
future modified clauses. In the European Union, you cannot grant an
***unlimited right*** on your ***future and undefined*** work without a
***defined counterpart*** (example=a salary).

- In French law, an author right is devided in two separate rights : the owner
right and the moral right. Every author (or community of authors) owns a
moral right on his/her work, even after the selling of rights. It has several
consequences which I wron't bother you with (even in RedHat attitude = the
renaming of a software is unmoral, bacause it makes you believe RedHat is the
original author of PostgreSQL).

e) SourceForge is a closed-source service

SourceForge migrated (=rewrote) their database server-side code from
PostgreSQL to Oracle, mainly for legal reasond. This new work gives them the
ability to change licences.

As a consequence, SF did not release their code for a year or so. SF can now
be considered as a closed-source service.

f) I would discourage anyone from registering on SourceForge. Any organization
is meant to be created, to live ... and die. Microsoft, Oracle and
SourceForge will probably die sooner or later.

On the other hand, open-source project provider, like Savannah or better
GBOrg, which are owned by non-profit organization or individuals releasing
their source code under the GNU, will never die. This make a huge difference.

Now, what if Microsoft purchased OSDN? What would be the consequences?

Cheers,
Jean-Michel



Re: SourceForge policy on http://sourceforge.net/tos/tos.php

From
Michael Poole
Date:
Jean-Michel POURE <jm.poure@freesurf.fr> writes:

> a) Acceptance of Terms
> 
> "We reserve the right, at our discretion, to change, modify, add or remove 
> portions of these terms periodically. Such modifications shall be effective 
> immediately upon posting of the modified agreement to the website. Your 
> continued use of the SourceForge.net website following the posting of changes 
> to these terms and conditions will mean that you accept those changes."
> 
> -> My point of view : SourceForge has an unlimited right to change the content 
> of the TOS. A simpe post of the modified TOS is sufficient. For example, they 
> may at any time charge access to their web site.

This is standard legalities.  They are a corporate entity; if there is
a gap that leaves them liable for someone else's actions, they have to
either be able to update their TOS -- or they must stop providing the
service.

> b) Licensing of code
> 
> "In each such case, the submitting user grants SourceForge.net the 
> royalty-free, perpetual, irrevocable, non-exclusive and fully sublicensable 
> right and license to use, reproduce, modify, adapt, publish, translate, 
> create derivative works from, distribute, perform and display such Content 
> (in whole or part) worldwide and/or to incorporate it in other works in any 
> form, media, or technology now known or later developed, all subject to the 
> terms of any applicable approved license."
> 
> -> My point of view : More surprisingly, SourceForge owns all content posted 
> on SourceForge. For legal reasons, SF licensing agreement is subject to the 
> terms of any applicable approved license. But, the words *** or later 
> development *** are thrilling.

That is simply their legal way of saying "You may only publish 'open
source' software and content on SourceForge" -- which is made clear
when you sign up for a new project anyway.  If you want them to
distribute your software over the Internet, why do you care if they
later distribute it over Planetnet?  (The "in any ... technology
... later developed" does not scare me.)  You must choose which
license to use; if you do not want to use any of the approved
licenses, *then* you might not want to use SourceForge.

> c) Termination
> 
> "We may terminate a user's account in our absolute discretion and for any 
> reason. We are especially likely to terminate for reasons that include, but 
> are not limited to, the following: 1.) violation of these Terms; 2.) abuse of 
> site resources or attempt to gain unauthorized entry to the site or site 
> resources; 3.) use of Service in a manner inconsistent with the Purpose; 4.) 
> a user's request for such termination; and 5.) requirement of applicable law, 
> regulation, court or governing agency order.
> 
> -> My point of view : As a consequence, SourceForge does not allow a user to 
> unregister from SourceForge. I tried to unregister a project from SF, without 
> success. Why? Because SF owns the (your) project rights.

Your project has nothing to do with their ability to terminate
accounts.  When I tried to unregister a project from SF, it took
months, but they eventually did it.  Maybe it helped that we were just
renaming the project to something else on SF and had already moved the
CVS tree.

> d) Incompatibility with local european laws
> 
> This contract does not comply with the European laws :
> 
> - SF may change the licensing terms at any time, without limitation of the 
> future modified clauses. In the European Union, you cannot grant an 
> ***unlimited right*** on your ***future and undefined*** work without a 
> ***defined counterpart*** (example=a salary).

Where does it say SF may change the licensing terms?  If you do not
want them to change the licensing terms much, you can do something
like using GPL instead of BSD.  Neither do they claim any right at all
on your future work, unless you send those works to them -- "Licensing
of code" merely says that once you send them something, they have an
unlimited right to use and redistribute it.

> - In French law, an author right is devided in two separate rights : the owner 
> right and the moral right. Every author (or community of authors) owns a 
> moral right on his/her work, even after the selling of rights. It has several 
> consequences which I wron't bother you with (even in RedHat attitude = the 
> renaming of a software is unmoral, bacause it makes you believe RedHat is the 
> original author of PostgreSQL).

This is partially a license issue, and partially an international law
issue, but it has little bearing on whether one uses SourceForge or
not; *any* user of the code can exercise the same rights.  You say
below that you prefer Savannah over SourceForge, but Savannah does
little enough to acknowledge that their code is based on SourceForge's
code.  Why criticize RedHat for doing the same thing?

> e) SourceForge is a closed-source service
> 
> SourceForge migrated (=rewrote) their database server-side code from 
> PostgreSQL to Oracle, mainly for legal reasond. This new work gives them the 
> ability to change licences.
> 
> As a consequence, SF did not release their code for a year or so. SF can now 
> be considered as a closed-source service.

Last time I checked, SourceForge 2.5 and before were still GPLed, and
some people do work to maintain it.  However, use of a service is
different than licensing software.  Google is closed source -- do you
refuse to use the services they provide?

> f) I would discourage anyone from registering on SourceForge. Any organization 
> is meant to be created, to live ... and die. Microsoft, Oracle and 
> SourceForge will probably die sooner or later. 

Microsoft, Oracle, SourceForge, and the FSF can all die, yes.

> On the other hand, open-source project provider, like Savannah or better 
> GBOrg, which are owned by non-profit organization or individuals releasing 
> their source code under the GNU, will never die. This make a huge difference.

Why not?  People get hit by busses.  Organizations lose favor, or run
low on funding, and eventually go away too.  Licensing and wide
distribution of the code is what guarantees it will never die, not the
mass distributor(s).

> Now, what if Microsoft purchased OSDN? What would be the consequences?

What if Microsoft hired all of the Postgres committers?  (Empty
questions can be easily turned around, so it is better to be specific
in your concerns.)

Michael Poole