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 decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
