Mon Nov 12 06:09:44 PST 2012
- Previous message: [Slony1-general] Lock set behaviour difference between 2.0 and 2.1
- Next message: [Slony1-general] Lock set behaviour difference between 2.0 and 2.1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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. I think you could still do LOCK SET(...) LOCK SET(...) MOVE SET(...) MOVE SET(...) just NOT inside of a TRY block.
- Previous message: [Slony1-general] Lock set behaviour difference between 2.0 and 2.1
- Next message: [Slony1-general] Lock set behaviour difference between 2.0 and 2.1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list