<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="yiv1044315092"><div id="yui_3_16_0_ym19_1_1491234737277_25621"><div style="color:#000;background-color:#fff;font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px;" id="yui_3_16_0_ym19_1_1491234737277_25620"><div id="yiv1044315092"><div id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_21947"><div style="color:#000;background-color:#fff;font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px;" id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_21946"><div id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10746"><div dir="ltr" id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_21981"><div id="yui_3_16_0_ym19_1_1491234737277_26285">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).</div><div id="yui_3_16_0_ym19_1_1491234737277_26803"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1491234737277_26286">So I expose directly my problem with Slony 2.2 again :<br></div></div><div id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_21983"><br></div><div id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_21982">In my company we use Slony not only for replication but also as a queue management system. </div>We implement tables representing event queues, each node is master on an event queue to post messages.<br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10866" clear="none">We
 place triggers on the event queues which are activated only on slave 
nodes (with a function checking the&nbsp; set_origin of the table and the 
local node id). <br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10867" clear="none">In
 the trigger we change locally the session_replication_role (to origin)&nbsp;
 to do updates in the target node (but only on master tables of this 
node) <br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10868" clear="none"></div><div id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10869">and get back&nbsp; the session_replication_role to replica at the end of the trigger. <br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10870" clear="none"></div><div id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10871"><br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10872" clear="none"></div>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.<br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10873" clear="none"><br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10874" clear="none">Everything was fine up to Slony 2.1 but the 2.2 version didn't work any more. <br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10875" clear="none">The logTrigger was triggered during the logApply trigger but didn't do any insertion in sl_log tables. <br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10876" clear="none"><br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10877" clear="none">In
 src/backend/slony1_funcs.c, the cluster status doesn't have the 
plan_insert_logs initialized in the context of the logApply trigger.<br id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10878" clear="none"><div dir="ltr" id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_10879"><div dir="ltr" id="yiv1044315092yui_3_16_0_ym19_1_1491234737277_12477"><div id="yui_3_16_0_ym19_1_1491234737277_26379">I tested the existence of plan_active_log to recreate it if needed in the logTrigger C code, and apparently this works... <br></div><div id="yui_3_16_0_ym19_1_1491234737277_26471"><br></div><div id="yui_3_16_0_ym19_1_1491234737277_26507">Is it a bug or a feature we used for years without any warranties ? <br></div><div id="yui_3_16_0_ym19_1_1491234737277_26647"><br></div><div id="yui_3_16_0_ym19_1_1491234737277_26648" dir="ltr">I can give you a full SQL example and the correction in slony1_funcs.c if needed. <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1491234737277_26827"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1491234737277_26828">Regards,</div><div dir="ltr" id="yui_3_16_0_ym19_1_1491234737277_26829">Cédric.<br></div></div></div> </div></div></div><br></div></div></div></div></body></html>