Thread: replication modules on postgres
Hi all! Some time back I discussed the inclusion of replication (e.g. postgres-R) into postgres. One of the technical reasons that I understand against such a move is the application dependence of replication. PostgresR requires a large amount of code change in postgres. All this leads to a bitter taste in the minds of my managers who want to use postgres but can't do without replication, and also they want to only rely on the main dev path of postgres itself. This problem only offers one technically feasible alternative(AFAIK). If the postgres maintainers would provide a standard API for pluggable replication modules, then it would be possible for the enterprises to pick up reliable replication modules from the market and use. This API obviously would have to be able to support the whole wide variety of replication techniques, and hence requires a keen understanding of all the issues involved. Is the core Postgres team thinking of providing such an API? Would they be inclined to do so in the future? Finally, in case they are not, would the postgres team be willing to help independent contributors (like me) to standardize such an API and accept the changes in the database if we wished to contribute? Please let me know of any thoughts on this. thanks, Naveen -- "Stand for something, or you will fall for nothing."
> Some time back I discussed the inclusion of replication (e.g. > postgres-R) into postgres. > One of the technical reasons that I understand against such a move is > the application dependence of replication. PostgresR requires a large > amount of code change in postgres. > All this leads to a bitter taste in the minds of my managers who want > to use postgres but can't do without replication, and also they want > to only rely on the main dev path of postgres itself. Try using Slony, it's actually up to date: http://www.slony.info/ Chris
On Mon, 2 Aug 2004, chinni wrote: > Is the core Postgres team thinking of providing such an API? > Would they be inclined to do so in the future? > Finally, in case they are not, would the postgres team be willing to > help independent contributors (like me) to standardize such an API and > accept the changes in the database if we wished to contribute? There is no easy answer to this ... the problem is that right now there are about a half dozen or so replication solutions out there, and out of those, only one (that I'm aware of) requires any changes to the server itself, the rest are layered solutions that run over top of the existing binary ... as such, there is really nothing to provide an API *for*. In fact, the one that an API would have some benefit for is for PostgreSQL v7.2, with work under way to bring it up to v7.4 ... so it is based on technology that is >1 year old ... As to the 'willing to help' ... I would suggest writing up a proposal before you do all the work, as to the direction you want to take, and how you invision implementing it .. get feedback at the technical, not coding, level, before you start ... One thing you might do is join the Postgres-R project, and work with them on an API based on their model, that will plug into the latest -HEAD ... that will at least give you a working model to work from, as to what requirements there are for an API ... the only worry I'd have is a new one coming along that needs to plug in at a different point in the server ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 2004-08-02 at 08:51, chinni wrote: > Hi all! > Some time back I discussed the inclusion of replication (e.g. > postgres-R) into postgres. > One of the technical reasons that I understand against such a move is > the application dependence of replication. PostgresR requires a large > amount of code change in postgres. > All this leads to a bitter taste in the minds of my managers who want > to use postgres but can't do without replication, and also they want > to only rely on the main dev path of postgres itself. > > This problem only offers one technically feasible alternative(AFAIK). > If the postgres maintainers would provide a standard API for pluggable > replication modules, then it would be possible for the enterprises to > pick up reliable replication modules from the market and use. Considering that all the other solutions do NOT require changes in the postgresql backend code, I'd say that the libpq IS the pluggable interface they already use. I.e. this is a non-problem. > This API obviously would have to be able to support the whole wide > variety of replication techniques, and hence requires a keen > understanding of all the issues involved. Actually, the simpler this interface, the better, as it is less likely to need to change from one version of pgsql to the next. Hence the use of the native communications protocol. Slony-I is pretty much done with stage one development, and should do what you need. Take a look at it and let us know where it's deficient, if anywhere...
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Mon, 2 Aug 2004, chinni wrote:
>> Is the core Postgres team thinking of providing such an API?
> the only worry I'd have is a new one
> coming along that needs to plug in at a different point in the server ...
That would be the major worry I'd have. AFAICS the requirements for
different forms of replication are so different that a "one size fits
all" API seems impossible. Perhaps an API that would allow plugging in
Postgres-R could be made, but I doubt it would be useful for anything
very much different from Postgres-R.
If you think you can define such an API, though, let's see a sketch ...
regards, tom lane