Neil Conway <[EMAIL PROTECTED]> writes: > Greg Copeland <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]