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 по дате отправления: