On 2/18/2005 4:10 AM, ?ncor Gonz?lez Sosa wrote:
> El Jueves, 17 de Febrero de 2005 19:17, Jan Wieck escribi?:
>> On 2/17/2005 2:08 PM, Andrew Sullivan wrote:
>> > On Thu, Feb 17, 2005 at 01:17:16PM -0500, Jan Wieck wrote:
>> >> On 2/16/2005 6:46 AM, Andrew Sullivan wrote:
>> >> >Yes.
>> >>
>> >> Actually not exactly. The query executed on the subscriber would be
>> >>
>> >>     update example_table set key = '4' where key = '4';
>> >>
>> >> The slony log trigger filters out unchanged columns. If that results in
>> >> no column change at all (empty SET clause in the update), it adds the
>> >> first key column so that the update becomes valid SQL.
>> >
>> > Sorry, I should have been clearer.  Jan is of course right that the
>> > trigger filters unchanged columns; but the OP wanted to know if it
>> > filters out queries which do no work or have no effect.  The answer
>> > to that, as far as I know, is no, and Jan's example above illustrates
>> > it.
>>
>> We (my stomach and I) had been thinking about filtering out NOOP's
>> entirely. But that would be in conflict with subscriber side enabled
>> user triggers, which do get called even if the update does in fact
>> nothing like the above example.
>>
>> The solution would be another attribute on sl_table which is used to
>> define another argument for the log trigger which controls the filter.
> 
> So, if this feature is implemented, it would be easy to make Slony skip 
> "unnecessary" statements. If, in addition, the mechanism that avoid you to 
> update a subscribed table (What is it? A simple trigger?) is disabled...
> would it be possible to set a double (symetric) master-slave relation between 
> the tables to have a "multimaster" (with only two implied databases) system?
> 
> I mean, Table1 in Host1 is a master of Table1 in Host2 and Table1 in Host2 is 
> a master of Table1 in Host1. Of course, there is not conflict resolution at 
> all but, at least, there are not infinite loops of updates (if unnecessary 
> updates are skipped) unless when a same record is updated in both databases 
> "simultaneously". In fact, it's not a real multimaster system because there 
> are a lot of situations that must be explicitly avoided by the applications 
> using the databases but...
> 
> Would it work? Would it explode?

I think it could have some very "funny" side effects. Suppose node1 
updates a value to A and node 2 does simultaneously update it to B. Now 
both replicate their changes so node1 ends up with B and node2 ends up 
with A. I want to see the faces of the users ;-)


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #