Neil Conway <nconway@klamath.dyndns.org> writes:
> Greg Copeland <greg@CopelandConsulting.Net> writes:
>> I see. So the intension of the core developers is to have one and only
>> one replication solution?
> Not being a core developer, I can't comment on their intentions.
Well, I am, but I'm only speaking for myself here:
I think there's definitely a need for at least two replication
implementations: sync and async. The space of requirements is wide
enough that there's not a one-size-fits-all solution. You might care
to look at Darren Johnson's OSCON slides for more about this:
http://conferences.oreillynet.com/cs/os2002/view/e_sess/3280
I think there is room for several replication solutions for Postgres
(three or four, maybe).
It's difficult to say what will wind up in our core distribution.
A tightly linked implementation like Postgres-R is really impractical
as an add-on: you need enough mods of the core code that it'd be a
nightmare to try to maintain if it's not integrated into the regular
CVS tree. So assuming that the Postgres-R project gets to the point
of usefulness, I'd vote in favor of integrating it. On the other hand,
it's possible to do good stuff without touching the core code at all
(cf. PostgreSQL Inc's rserv) and in that case there may or may not be
any interest in integrating the code. It's really gonna depend mostly
on the wishes of the people who develop the replication solutions,
I think.
I can foresee a time when there are one or two replication solutions
that are included in the base distribution and others are available
separately. In fact, counting contrib/rserv that more or less describes
the state of affairs today. What we need is more work on the available
solutions to improve their quality and general usefulness.
As for the point at hand: I'm fairly dubious that a common monitoring
API will be very useful, considering how different the possible
replication approaches are. If Greg can prove me wrong, fine. But
I don't want to see us artificially constraining replication solutions
by insisting that they meet some prespecified API.
regards, tom lane