On 11-04-22 06:25 AM, Stuart Bishop wrote:
> On Sat, Apr 16, 2011 at 2:41 AM, Christopher Browne
> <cbbrowne at afilias.info>  wrote:
>> On Fri, Apr 15, 2011 at 2:16 PM, Steve Singer<ssinger at ca.afilias.info>  wrote:
>>> C)  We could get rid of try blocks.  Some people have commented that
>>> they don't behave as expected anyway and with the additional
>>> restrictions of changes 1) and 2) they are even less useful.
>>
>> I'd point not only to "less useful," but also to "less able to be
>> reasoned about" as an issue.
>>
>> The "intuitive" position is that TRY blocks are supposed to look like
>> something quasi-transactional; if there's a failure, "everything
>> should be rolled back."  That's certainly a cool idea to consider.
>>
>> Unfortunately, that's not remotely near to being how things are.  If
>> there are activities inside a TRY block that cross multiple nodes,
>> it's not reasonable to expect that all to roll back.  (We're not using
>> 2PC!)
>
> But it does seem to work well enough...
>
> eg. execute a number of SQL scripts in a try block. If one of them
> fails when applying to the master, it all rolls back. If they all
> work, the events get propagated and they are applied on the slaves and
> if this fails you have other problems. It might not be perfect, but it
> is better than a kick in the teeth and I would like to keep it.

So how do you feel about slonik obtaining the sl_event_lock on all nodes 
while it performs the execute script.   The concequence of this is that 
no new SYNC events will be generated on any node until ALL of your 
execute scripts (in that try block) commit.

This would mean that if you have nodes  1 hosting set 1, and node 2 
hosting set 2 an EXECUTE SCRIPT (or anything else) in a try block on 
node 1 would pause replication from node 2 (even between nodes 2 and 3). 
  Of course if you don't use a try block then sync event generation on 
node 2 won't be paused.