----- Original Message -----

> From: Steve Singer <ssinger at ca.afilias.info>
> To: Glyn Astill <glynastill at yahoo.co.uk>
> Cc: slony <slony1-general at lists.slony.info>
> Sent: Monday, 12 November 2012, 14:09
> Subject: Re: [Slony1-general] Lock set behaviour difference between 2.0 and 2.1
> 
> On 12-11-12 07:35 AM, Glyn Astill wrote:
>>> 
>> 
>>  Hi Steve,
>> 
>>  I've just tried the above on 2.1.2 and I get the same error message as 
> on 2.0.7  when I try to lock the second set:
>> 
>> 
>>  "cannot lock set - admin connection already in transaction"
>> 
>>  I'm guessing "lock set" and "move set" have to be 
> run consecutively?
>> 
> 
> Actually the issue is that the lock set needs to be in its own transaction so it 
> can't really be used in an 'active' try block except as the first 
> command (which the documentation say)
> 
> The message you are getting was apparently added with this commit.
> 
> commit d013758b4823e2d386a2a0738e0d9a5534f11556
> Author: Jan Wieck <JanWieck at yahoo.com>
> Date:   Thu Mar 18 22:47:00 2004 +0000
> 
>     Added "lock set", "unlock set" and "move set" 
> commands
>     to slonik. "lock set" requires to be the first statement
>     in a transaction since it actually needs to commit the
>     lockSet() call and then wait until the lock's xmax <=
>     xmin. To prevent accidential misuse we don't allow other
>     statements in the same transaction.
> 
>     Jan
> 
> 
> One solution is to allow LOCK SET to take/lock multiple sets at once (this 
> change won't happen before slony 2.3), but I'm not sure if there is a 
> different solution.

Ah that's what I was hoping for!

> 
> I think you could still do
> 
> LOCK SET(...)
> LOCK SET(...)
> MOVE SET(...)
> MOVE SET(...)
> 
> just NOT inside of a TRY block.
>

Yeah, it's just nice to be able to unlock the sets locked so far if something goes wrong half way through.