[Bucardo-general] bucardo internals and updates

[sym39]

Le 11/05/2015 20:23, Greg Sabino Mullane a écrit :
> Correct. All of the replication happens inside of a transaction, so
> other connections will only see the final state after all the changes
> have been applied.

Ok.
>
>> >2) About notifications, add/remove and always trigger:
>> >Each time a modification (add/remove/update) is done on a row, a
>> >trigger is called and notifies about the change. To make sure that
>> >notifications are sent on the slave, we have updated the triggers as
>> >always trigger.
>> >This works for add and remove, but as an update is done with delete
>> >followed by copy, we have some difficulties to make the distinction
>> >between a "real" add, a "real" remove and an update that leads to
>> >remove/add events.
>> >Any ideas about that?
> Do not set the triggers as 'always' - as you found out, that can lead
> to confusion. Why does the default trigger behavior (e.g. 'origin',
> not 'always'), work for you? There are some other workarounds that
> should be tried before resorting to setting triggers as 'always'.
In both the slave and the master, there is a daemon that listens for 
postgres notification (NOTIFY) messages.
The NOTIFY themselves are sent by specific triggers which role is only 
to sent notifications:
-when a new event is added in the events table;
-when an event is deleted in the events table;
-and when some important fields of the event tuple are modified.
In the deamon, a specific action related to the type of message 
(event_added, event_removed, event_updated) is done.
This was working correctly without failover. When the failover with 
bucardo was introduced, I thought I could simply change the "notify" 
triggers as always trigger, so that the daemon that is on the slave be 
notified the same way the master daemon is. But this does not work 
correctly, like I explained above.
I amcurrently thinking of relying on another bus to propagate the 
messages on the slave instead of relying of the postgres notification 
that requires 'always' trigger to work "more or less" . Then I could 
restore the trigger as 'origin' trigger.

Thanks for your response, and regards,

Sylvain