I don't think your advice is correct, Shahaf. Obviously if I'm wrong,
I hope somebody will correct me.

See this Note from the documentation--especially the last phrase.
From: http://www.slony.info/documentation/ddlchanges.html
"Note:  Actually, as of version 1.1.5 and later, this is NOT TRUE. The
danger of someone making DDL changes that crosses replication sets
seems sufficiently palpable that slon has been changed to lock ALL
replicated tables, whether they are in the specified replication set
or not."

And even more surprising (disturbing?) is that Slony waits on locks
that have NOTHING to do with any of the replicated objects. For
example, if you have 11 tables in your database. 10 tables are in a
slony set. The 11th table is not replicated and has zero foreign-keys.
It is for all practical purposes, a "stand-alone" table. Yet Slony
will not be able to do things such as DDL changes (execute_script) or
subscribe if another process has a lock on that 11th table.

I have a patch to the code that is supposed to alleviate this problem.
It was sent to me by another list member. I've not yet had time to
review the code or test it.

I truly wish I understood more about this aspect of Slony.

> Message: 1
> Date: Tue, 1 Jul 2008 08:27:32 -0700
> From: Shahaf Abileah <shahaf at redfin.com>
> Subject: RE: [Slony1-general] how to prevent EXECUTE SCRIPT from
>        locking alltables
> To: "Cyril SCETBON" <scetbon at echo.fr>,
>        <slony1-general at lists.slony.info>
> Message-ID: <082D8A131DF72A4D88C908A1AD3DEB2204213AF8 at mail-1.rf.lan>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>
> 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.
>
> --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