I was running the DDL test against CVS HEAD; ran into the following failure:

$ ./run_test.sh testddl
[...various output elided...]
done
Execute a script on each node, one by one
execute DDL script on node 1
execute DDL script on node 2
./run_test.sh: ERROR: Slonik error see /tmp/slony-regress.w29367/slonik.log for details
insert into slony_tests (smoduleversion, sv_major, sv_minor, sv_patch, pg_version, uname_m, uname_r, uname_s, uname_v, hostname, tester_identity, testname, start_time, end_time, successful, failure_desc) values ('2.0.0', '2', '0', '0', 'PostgreSQL 8.3devel on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.3 20070601 (prerelease) (Debian 4.1.2-12)', 'i686', '2.6.20-1-686', 'Linux', '#1 SMP Tue Apr 24 21:52:11 UTC 2007',  'dba2.int.libertyrms.com', 'j.random.luser at example.net', 'testddl', '2007-06-28 20:33:14 UTC', '2007-06-28 20:35:32 UTC', 'false', 'Slonik error see /tmp/slony-regress.w29367/slonik.log for details');

cbbrowne at dba2:~> cat /tmp/slony-regress.w29367/slonik.log 
<stdin>:6: PGRES_FATAL_ERROR 
update table1 set seqed = nextval('t1seq'); - ERROR:  Slony-I: Table table1 is replicated and cannot be modified on a subscriber node
DDL script consisting of 5 SQL statements
DDL Statement 0: (0,22) [create sequence t1seq;]
DDL Statement 1: (22,67) [
alter table table1 add column seqed integer;]
DDL Statement 2: (67,135) [
alter table table1 alter column seqed set default nextval('t1seq');]
DDL Statement 3: (135,179) [
update table1 set seqed = nextval('t1seq');]
cbbrowne at dba2:~> cat /tmp/slony-regress.w29367/slonik.script 
CLUSTER NAME = slony_regress1;
NODE 1 ADMIN CONNINFO = 'dbname=slonyregress1 host=localhost user=cbbrowne port=5834';
NODE 2 ADMIN CONNINFO = 'dbname=slonyregress2 host=localhost user=cbbrowne port=5834';
NODE 3 ADMIN CONNINFO = 'dbname=slonyregress3 host=localhost user=cbbrowne port=5834';

  EXECUTE SCRIPT (
       SET ID = 1,
       FILENAME = 'testddl/ddl_update_part2.sql',
       EVENT NODE = 2,
       EXECUTE ONLY ON = 2
    );

Looking at the schema for table1 on the 2nd database:

slonyregress1@[local]:5834=# \c slonyregress2 
You are now connected to database "slonyregress2".
slonyregress2@[local]:5834=# \d table1
                         Table "public.table1"
 Column |  Type   |                      Modifiers                      
--------+---------+-----------------------------------------------------
 id     | integer | not null default nextval('table1_id_seq'::regclass)
 data   | text    | 
Indexes:
    "table1_pkey" PRIMARY KEY, btree (id)
Triggers:
    _slony_regress1_denyaccess BEFORE INSERT OR DELETE OR UPDATE ON table1 FOR EACH ROW EXECUTE PROCEDURE _slony_regress1.denyaccess('_slony_regress1')
Disabled Triggers:
    _slony_regress1_logtrigger AFTER INSERT OR DELETE OR UPDATE ON table1 FOR EACH ROW EXECUTE PROCEDURE _slony_regress1.logtrigger('_slony_regress1', '1', 'kv')

Wild speculation: Evidently the "denyaccess" trigger is not being
disabled when the EXECUTE SCRIPT request runs...

Evidently this is a good test :-).
-- 
output = ("cbbrowne" "@" "ca.afilias.info")
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)