On 04/03/2017 12:19 PM, Perotto Cédric wrote:
> 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).

The message did make it to the list 
(http://lists.slony.info/pipermail/slony1-hackers/2017-April/000563.html). 
   Some of the mailing list issues might be related to yahoo and DMARC 
issues. In the past other yahoo users have had issues.




>
> 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.

I am a bit confused about your usage of the word 'event', for clarity 
and so others aren't confused.

For purposes of below I am going to qualify 'event' as either 
'Application Event' or 'Slony event'.

When I say 'Slony event' I mean something corresponding to a row in 
sl_event.

By 'Application Event' I am refering to what I think your describing as 
this:

* You have a table that you have created named something like 
'myapp_event_queue'
* Your application does an 'INSERT INTO myapp_event_queue (....')
* On the replica you have a trigger that fires always on 
myapp_event_queue.  This trigger then changes session_replication_role 
and does stuff


I am of the opinion that the only way 'Slony events' should be created 
is either from slonik or slon.   I strongly discourage users from 
calling the slony stored functions to create slony events outside of 
slonik.  I originally thought that this was what you were doing but now 
I think maybe not.



I think the issue here in this case might be that the call stack when 
you replicate your 'Applciation Events' is

slon->logApply->your_trigger->logTrigger

The logTrigger is being called underneath the log apply.  The log Apply 
sets currentXid but doesn't initialize the variables needed by 
logTrigger.  What your doing should be safe and we can fix the 
logTrigger to later initialize the plans.

The potentially unsafe bits are when people generate their own 'Slony 
events' in the same transaction as data.

I'll try to produce a new patch later this week







>
> 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.
>