markokr@gmail.com ("Marko Kreen") writes:
> Also the design should be based on assumption that the target side
> is exactly in sync. Eg. DROP CASCADE should be replicated as DROP CASCADE.
> We should not make scheme more complex to survive cases where target
> is not in sync. That way madness lies. The effect should be like
> same SQL statements are applied to target by hand, no more, no less.
We have, already, in 8.4, a handling of triggers for TRUNCATE; the
reason why support hasn't made it into Slony-I yet relates quite
exactly to this...
The trouble comes in if you do TRUNCATE CASCADE; I'm not quite sure
how to collect together the multiple recordings of the trigger
functions that would be collected as a result; for it all to work,
safely, on the remote node, we'd need to apply all of those truncates
at once.
Note also that there is an issue with coordination of schemas; Slony-I
shuts off the RI triggers on subscribers, so that the target is fairly
certain to not be *entirely* in sync, by express intent.
Those are legitimate differences between source and target.
--
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/lsf.html
Rules of the Evil Overlord #145. "My dungeon cell decor will not
feature exposed pipes. While they add to the gloomy atmosphere, they
are good conductors of vibrations and a lot of prisoners know Morse
code." <http://www.eviloverlord.com/>