<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_1494093571661_28562">We have tested the patch, it fixed the issue.</div><div id="yui_3_16_0_ym19_1_1494093571661_28589"><br></div><div id="yui_3_16_0_ym19_1_1494093571661_28590">Thanks,<br>Cedric.<br></div><div id="yui_3_16_0_ym19_1_1494093571661_28540"><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 Samedi 15 avril 2017 2h33, Steve Singer <steve@ssinger.info> a écrit :<br></font></div> <br><br> <div class="y_msg_container"><div dir="ltr">On 04/03/2017 04:27 PM, Perotto Cédric wrote:<br clear="none">> Sorry for the wrong terminology, I was talking about 'Applciation<br clear="none">> Events' (with the call stack slon->logApply->my_trigger->logTrigger and<br clear="none">> the logTrigger not doing anything).<br clear="none">><br clear="none">> Thanks for the quick answer and inform me when you have produced a patch.<br clear="none">><br clear="none">> Cedric.<br clear="none">><br clear="none">><br clear="none">><br clear="none"><br clear="none">The attached pathces (0001 should be the same patch I sent out earlier, <br clear="none">0002 modifies it) should fix the issue.<br clear="none"><br clear="none">Let me know if it does.<div class="yqt4832070998" id="yqtfd83920"><br clear="none"><br clear="none"><br clear="none"><br clear="none">><br clear="none">><br clear="none">> Le Lundi 3 avril 2017 21h57, Steve Singer <<a shape="rect" ymailto="mailto:steve@ssinger.info" href="mailto:steve@ssinger.info">steve@ssinger.info</a>> a écrit :<br clear="none">><br clear="none">><br clear="none">> 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<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">> ><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.</div><br clear="none">> ><br clear="none">><br clear="none">><br clear="none">><br clear="none">><br clear="none">><br clear="none">> _______________________________________________<br clear="none">> Slony1-hackers mailing list<br clear="none">> <a shape="rect" ymailto="mailto:Slony1-hackers@lists.slony.info" href="mailto:Slony1-hackers@lists.slony.info">Slony1-hackers@lists.slony.info</a><br clear="none">> <a shape="rect" href="http://lists.slony.info/mailman/listinfo/slony1-hackers" target="_blank">http://lists.slony.info/mailman/listinfo/slony1-hackers</a><div class="yqt4832070998" id="yqtfd38916"><br clear="none">><br clear="none"><br clear="none"></div></div><br><br></div> </div> </div> </div></div></body></html>