On Jul 22, 2008, at 4:43 PM, Markus Wanner wrote:
Decibel! wrote:ISTM that both londiste and Slony would be able to make use of these improvements as well. A modular replication system should be able to use a variety of methods for logging data changes and then applying them on a subscriber, so long as some kind of common transport can be agreed upon (such as text). So having a change capture and apply mechanism that isn't dependent on a lot of extra stuff would be generally useful to any replication mechanism.Hm.. yeah, that's a good hint. However, I'm not sure how londiste and Slony would interface with these internal methods. That would require some sort of special replication triggers or something. But when to fire them? After every statement (sync)? Just before commit (eager)? After commit (lazy)? (These are the points in Postgres-R, where the internal methods are called).
Currently, londiste triggers are per-row, not deferred. IIRC, londiste is the same. ISTM it'd be much better if we had per- statement triggers that could see what data had changed; that'd likely be a lot more efficient than doing stuff per-row.
In any case, both replication systems should work with either sync or eager. I can't see them working with lazy.
What about just making all three available?
I'm claiming that Postgres-R is modular (enough). But I'm unsure what interface it could provide to the outer world.
Yeah. I suspect that Postgres-R could end up taking the place of the replica-hooks mailing list (and more, of course).
-- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828
smime.p7s
Description: S/MIME cryptographic signature
