The phenomenon in the above bug report has been observed by a couple
of people:
<http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1522>

"When adding a column to a table, EXECUTE SCRIPT should (according to
the documentation in chapter 14, "Database Schema Changes") only
request exclusive locks on those tables which are in the replication
set specified in the EXECUTE SCRIPT command. What it did in my
installation, however, was apparently to request exclusive locks on
all tables in all replication sets (effectively all tables in the
database). After trying for a while, slonik failed with an error
message relating to a deadlock situation during a request for an
exclusive lock on a table in another replication set."

Tracing back the change, I see it committed in October, thus:

http://gborg.postgresql.org/pipermail/slony1-commit/2005-October/000748.html

Log Message:
-----------
Let EXECUTE SCRIPT restore system catalog changes on all tables of all
sets. Otherwise, DDL affecting multiple sets is not possible.

The intent is pretty clear, here.

The new behaviour, introduced in October, definitely conflicts with
the documentation.

Three options seem plausible:

1.  Should I simply "fix" the documentation to conform with the
present implementation?

Pro:
- Simplifies system behaviour
- Simplifies choices

Con:
- We lose, here, the ability to only 'unlock for DDL purposes' 
  those tables in a single set
- It would be nice to be able to just lock/DDL-update the 5 tables in
  one little set, which may be less interruption to the applications

2.  Should I roll it back?

Pro:
- No documentation changes needed :-)

Con: 
- There is no way to specify that multiple sets worth of tables need
  to be locked for a given DDL change

Gripping Hand:
- MERGE SET, SET MOVE TABLE, CREATE SET can, between them, be used to
  shift things around to achieve any desired partitioning of tables.

3.  Add an additional option to EXECUTE SCRIPT to give the choice...

in effect:

execute script (set id=all, filename='/tmp/something.sql', event node=1);

Pro:
- Makes the choice explicit

Con:
- A fair bit of work; some slonik parser changes, function signature
  changes, documentation changes

If I hear nothing, I expect I'll go with "option #1."  In principle,
#3 is the "cleanest," but it's definitely the most work.
-- 
output = reverse("ofni.sailifa.ac" "@" "enworbbc")
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)