Обсуждение: 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