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