http://www.slony.info/bugzilla/show_bug.cgi?id=229

           Summary: creating a set then adding a table to a different set
                    can deadlock
           Product: Slony-I
           Version: devel
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: slonik
        AssignedTo: slony1-bugs at lists.slony.info
        ReportedBy: ssinger at ca.afilias.info
                CC: slony1-bugs at lists.slony.info
   Estimated Hours: 0.0


A tester has reported in In 2.1.0 beta3:

A slonik script such as 

create set(id=2, origin=2 ,comment='second set');
create set(id=3, origin=3 ,comment='second set');
set add table(set id=2,origin=2,  tables='disorder.do_item_*');

----

can hang slonik where slonik keeps waiting for an event confirmation that it
never sees.

The issue seems to be that the add table code will:

1. Open a transaction and obtain a lock on sl_config_lock on the origin node
(node 2)
2. perform an implicit 'wait for event' to ensure that the last event submitted
to node 3 (the previous origin) has propagated.

However because slonik has a lock on sl_config_lock on node 2, the slon for
node 2 (the remote worker) might not be able to replicate events to node 2 (the
store node) because applying a many events to node 2 requires obtaining the
sl_config_lock (and sometimes the sl_event_lock).

slonik should not be invoking the implicit 'wait for' behaviour when it is
holding an open transaction.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.