<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px"><div id="yui_3_16_0_ym19_1_1491242992568_33994">Sorry for the wrong terminology, I was talking about 'Applciation Events' (with the call stack slon->logApply->my_trigger->logTrigger and the logTrigger not doing anything).</div><div id="yui_3_16_0_ym19_1_1491242992568_34166"><br></div><div id="yui_3_16_0_ym19_1_1491242992568_34167">Thanks for the quick answer and inform me when you have produced a patch.</div><div id="yui_3_16_0_ym19_1_1491242992568_34236"><br></div><div id="yui_3_16_0_ym19_1_1491242992568_34238">Cedric.<br></div><div id="yui_3_16_0_ym19_1_1491242992568_34237"><br></div><div id="yui_3_16_0_ym19_1_1491242992568_34073"><br></div><div id="yui_3_16_0_ym19_1_1491242992568_34079"><br></div><div id="yui_3_16_0_ym19_1_1491242992568_33890"><span></span></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> Le Lundi 3 avril 2017 21h57, Steve Singer <steve@ssinger.info> a écrit :<br></font></div> <br><br> <div class="y_msg_container"><div dir="ltr">On 04/03/2017 12:19 PM, Perotto Cédric wrote:<br clear="none">> Hello and sorry for the direct emails but the bug tracker and the<br clear="none">> mailing list @lists.slony.info appear to be down (mailer-daemon message<br clear="none">> No mx record found for domain=lists.slony.info).<br clear="none"><br clear="none">The message did make it to the list <br clear="none">(<a shape="rect" href="http://lists.slony.info/pipermail/slony1-hackers/2017-April/000563.html" target="_blank">http://lists.slony.info/pipermail/slony1-hackers/2017-April/000563.html</a>). <br clear="none"> Some of the mailing list issues might be related to yahoo and DMARC <br clear="none">issues. In the past other yahoo users have had issues.<br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none">><br clear="none">> So I expose directly my problem with Slony 2.2 again :<br clear="none">><br clear="none">> In my company we use Slony not only for replication but also as a queue<br clear="none">> management system.<br clear="none">> We implement tables representing event queues, each node is master on an<br clear="none">> event queue to post messages.<br clear="none">> We place triggers on the event queues which are activated only on slave<br clear="none">> nodes (with a function checking the set_origin of the table and the<br clear="none">> local node id).<br clear="none">> In the trigger we change locally the session_replication_role (to<br clear="none">> origin) to do updates in the target node (but only on master tables of<br clear="none">> this node)<br clear="none">> and get back the session_replication_role to replica at the end of the<br clear="none">> trigger.<br clear="none"><br clear="none">I am a bit confused about your usage of the word 'event', for clarity <br clear="none">and so others aren't confused.<br clear="none"><br clear="none">For purposes of below I am going to qualify 'event' as either <br clear="none">'Application Event' or 'Slony event'.<br clear="none"><br clear="none">When I say 'Slony event' I mean something corresponding to a row in <br clear="none">sl_event.<br clear="none"><br clear="none">By 'Application Event' I am refering to what I think your describing as <br clear="none">this:<br clear="none"><br clear="none">* You have a table that you have created named something like <br clear="none">'myapp_event_queue'<br clear="none">* Your application does an 'INSERT INTO myapp_event_queue (....')<br clear="none">* On the replica you have a trigger that fires always on <br clear="none">myapp_event_queue. This trigger then changes session_replication_role <br clear="none">and does stuff<br clear="none"><br clear="none"><br clear="none">I am of the opinion that the only way 'Slony events' should be created <br clear="none">is either from slonik or slon. I strongly discourage users from <br clear="none">calling the slony stored functions to create slony events outside of <br clear="none">slonik. I originally thought that this was what you were doing but now <br clear="none">I think maybe not.<br clear="none"><br clear="none"><br clear="none"><br clear="none">I think the issue here in this case might be that the call stack when <br clear="none">you replicate your 'Applciation Events' is<br clear="none"><br clear="none">slon->logApply->your_trigger->logTrigger<br clear="none"><br clear="none">The logTrigger is being called underneath the log apply. The log Apply <br clear="none">sets currentXid but doesn't initialize the variables needed by <br clear="none">logTrigger. What your doing should be safe and we can fix the <br clear="none">logTrigger to later initialize the plans.<br clear="none"><br clear="none">The potentially unsafe bits are when people generate their own 'Slony <br clear="none">events' in the same transaction as data.<br clear="none"><br clear="none">I'll try to produce a new patch later this week<div class="yqt8116840083" id="yqtfd01279"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none">><br clear="none">> That way data changed during the execution of the trigger should be<br clear="none">> logged to slony (through the logTrigger) then replicated back to the<br clear="none">> original node.<br clear="none">><br clear="none">> Everything was fine up to Slony 2.1 but the 2.2 version didn't work any<br clear="none">> more.<br clear="none">> The logTrigger was triggered during the logApply trigger but didn't do<br clear="none">> any insertion in sl_log tables.<br clear="none">><br clear="none">> In src/backend/slony1_funcs.c, the cluster status doesn't have the<br clear="none">> plan_insert_logs initialized in the context of the logApply trigger.<br clear="none">> I tested the existence of plan_active_log to recreate it if needed in<br clear="none">> the logTrigger C code, and apparently this works...<br clear="none">><br clear="none">> Is it a bug or a feature we used for years without any warranties ?<br clear="none">><br clear="none">> I can give you a full SQL example and the correction in slony1_funcs.c<br clear="none">> if needed.<br clear="none">><br clear="none">> Regards,<br clear="none">> Cédric.<br clear="none">><br clear="none"><br clear="none"></div></div><br><br></div> </div> </div> </div></div></body></html>