Re: Integrating Replication into Core

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Integrating Replication into Core
Дата
Msg-id 4989398A-A876-4093-88F9-FE74B3E7C1AC@decibel.org
обсуждение исходный текст
Ответ на Re: Integrating Replication into Core  (Markus Schiltknecht <markus@bluegap.ch>)
Ответы Re: Integrating Replication into Core  (Markus Schiltknecht <markus@bluegap.ch>)
Re: Integrating Replication into Core  (Andrew Sullivan <ajs@crankycanuck.ca>)
Список pgsql-hackers
On Nov 28, 2006, at 10:18 AM, Markus Schiltknecht wrote:
>> Well, part of the problem is there isn't much to say to code that I
>> can't look at.  I can play with it on the live CD, but so far the
>> source isn't on the web page at postgres-r.org, which is the only
>> source I know for it.  This makes the whole matter trickier for
>> potential adopters, because it's basically a black box.
>
> Very understandable. I'm trying to find ways to open source  
> Postgres-R.

Related to that, and your comment about people not using Postgres- 
R... 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.  
Contrast this with Slony, where there are no back-end changes and the  
trigger code (which is essentially the only thing that touches your  
live data) is readily visible just via \df+. That makes it very easy  
for people to convince themselves that Slony is unlikely to hose  
their data. Of course at this point there's enough people using Slony  
that that's no longer a concern, but back when it was introduced it  
would have been.

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

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.  
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.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: old synchronized scan patch
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: FOR SHARE vs FOR UPDATE locks