Perotto Cédric cedric.perotto at yahoo.fr
Mon Apr 3 09:19:03 PDT 2017
Hello and sorry for the direct emails but the bug tracker and the mailing list @lists.slony.info appear to be down (mailer-daemon message No mx record found for domain=lists.slony.info).
So I expose directly my problem with Slony 2.2 again :

In my company we use Slony not only for replication but also as a queue management system. We implement tables representing event queues, each node is master on an event queue to post messages.
We place triggers on the event queues which are activated only on slave nodes (with a function checking the  set_origin of the table and the local node id). 
In the trigger we change locally the session_replication_role (to origin)  to do updates in the target node (but only on master tables of this node) 
and get back  the session_replication_role to replica at the end of the trigger. 

That way data changed during the execution of the trigger should be logged to slony (through the logTrigger) then replicated back to the original node.

Everything was fine up to Slony 2.1 but the 2.2 version didn't work any more. 
The logTrigger was triggered during the logApply trigger but didn't do any insertion in sl_log tables. 

In src/backend/slony1_funcs.c, the cluster status doesn't have the plan_insert_logs initialized in the context of the logApply trigger.
I tested the existence of plan_active_log to recreate it if needed in the logTrigger C code, and apparently this works... 

Is it a bug or a feature we used for years without any warranties ? 

I can give you a full SQL example and the correction in slony1_funcs.c if needed. 

Regards,Cédric.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-hackers/attachments/20170403/14a123bd/attachment.htm 


More information about the Slony1-hackers mailing list