On Wed, 26 Jul 2006 10:49:25 +0200 Csaba Nagy <[EMAIL PROTECTED]> wrote:
> Gaviun, > > > We can run this script again and again, and after a few seconds get a > > deadlock on a different table each time. The really annoying thing here is > > the deadlocked table isn't even one we want to ALTER. Is there anything we > > can do here except for 'try again at 4am when things are quiet'? > > >From what I understood, slony will lock all tables in the set and remove > the slony triggers before executing the script. It cannot possibly know > which tables will be modified by the script, OK I thought there might have been a 'dry run' in a BEGIN/ROLLBACK block which watched which tables were being affected. Is this kind of thing planned for a future release? > and it must lock the tables > so nobody touches them between dropping the slony trigger, executing the > script and recreating the slony triggers. So it locks all the tables in > the set, in the order you defined them in the set. That I don't understand, because I specified the script to run on set 2, but I am only seeing deadlocks on tables which are only in set 1! :( > If you have > concurrently running transactions which lock tables in other order, you > can easily get deadlocks... > > So very likely the answer is do it at 4AM. <slump> Cheers, Gavin. _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
