Shahaf Abileah wrote:
> You can change your configuration such that the tables that you're
> looking to alter are in their own set.  That will still cause them to be
> locked, but at least it won't cause the other ones to be locked.
>   
that won't be the case, cause in version > 1.1 all replicated tables are 
locked.
> Also, in certain situations you might be able to run the alter command
> on each of the slaves and then on the master.  E.g. if you're adding a
> new column that allows null values, then it might be possible to alter
> the slaves even while rows are being inserted into the master.  You will
> still be taking a lock on the table while altering it, but at least
> you're not locking multiple tables at a time across multiple machines.
> Not sure if this is recommended practice.
>   
We had to use this method but it's not working with new columns. Slony 
Triggers are based on the number of columns, see the third argument of 
the "_clustername_logtrigger" triggers added on your tables.
> --S
>
> -----Original Message-----
> From: slony1-general-bounces at lists.slony.info
> [mailto:slony1-general-bounces at lists.slony.info] On Behalf Of Cyril
> SCETBON
> Sent: Tuesday, July 01, 2008 3:01 AM
> To: slony1-general at lists.slony.info
> Subject: [Slony1-general] how to prevent EXECUTE SCRIPT from locking
> alltables
>
> Hi,
>
> We got a cluster configuration with something like 500 tables. Sometimes
>
> we have to add columns to tables. Today we're using execute script which
>
> locks all tables and not only the tables that belong to the set 
> specified in this command. We have a lot of DML statement and these 
> locks are really disturbing our application.
>
> Are there other possibilities of using EXECUTE SCRIPT ? Is there a bad 
> and a good use of this command ?
>
> Thanks
>   

-- 
Cyril SCETBON