Re: Integrating Replication into Core

Поиск
Список
Период
Сортировка
От Markus Schiltknecht
Тема Re: Integrating Replication into Core
Дата
Msg-id 45752901.40306@bluegap.ch
обсуждение исходный текст
Ответ на Re: Integrating Replication into Core  (Jim Nasby <decibel@decibel.org>)
Список pgsql-hackers
Hi,

Jim Nasby wrote:
> Related to that, and your comment about people not using Postgres-R... 

I commented about the feedback I got, which would include rants about 
why it's not open source on such. But I didn't even get such responses.

I'm not supposing anybody to use Postgres-R currently. I don't use it in 
production myself. And the LiveCD currently serves mainly as an evidence 
for real code behind my words. ;-)

> I think it's going to be very, very hard to get people to seriously 
> consider using Postgres-R while it's essentially a fork of the community 
> code, with little/no visibility into what changes have been made and how 
> they could affect data stored in the database. 

Agreed.

> Given the nature of Postgres-R, I suppose there's no real way people 
> could become comfortable without looking at most/all of the code, since 
> it does tie pretty deeply into the backend. 

Most *people* use PostgreSQL in production without having ever looked at 
it's source code. Why should *they* want to look at Postgres-R sources?

I surely see that I could gain *developers* acceptance by opening up the 
source code. Please note that I'm absolutely for open source software, I 
always wanted to release my changes to Postgres-R under a BSD license 
one day.

I'm so much for open source software that I want to make a living from 
writing OSS. I simply don't know exactly how to do that, yet. So I'm 
keeping Postgres-R closed to leave me more options open.

> But that's one way that 
> having published hooks would help; if you could at least put the code 
> that touches the guts of the database and the source data out in the 
> open, people might be more willing to give Postgres-R a try.

I don't really buy that argument. It would be quite some work for me and 
not really help other developers, because the real code is still hidden 
away.

> You also mentioned putting IPC in the backend, since it's something that 
> you need. I think breaking something as complex as replication into 
> smaller chunks that can stand on their own is a great idea.

Agreed.

But once again, responses on my trivial IMessages implementations 
were... zero. Not even complaints about how lacking it is. Or discussing 
performance of pipes vs. this shared memory message passing approach. 
Nothing. Why should I work on something nobody else seems to be 
interested in?

> Oracle's 
> replication does this, and I wish Slony would. Having access to the 
> queuing/communications mechanism that the Slony folks have built would 
> be very useful. So I'd definitely encourage making subsets of Postgres-R 
> functionality available, and promoting them via pgFoundry.

Agreed.

I myself have thought about splitting some things out (i.e. this IPC 
stuff, another chunk to split out could be the GCS interface). It could 
make testing and development easier. But making it available via 
pgFoundry and promoting it as a separate project is another story which 
certainly depends on some interested people asking for it.

If Linus didn't get any answers to his famous post "What would you like 
to see most in minix?" he most probably wouldn't have published Linux.

Regards

Markus



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: "Compacting" a relation
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: Postgres95 archives in mbox format