On Sat, 2007-03-17 at 11:28 +0200, Mikko Partio wrote:
> Hi,
> 
> slonik's EXECUTE SCRIPT -documentation says that:
> 
> EXECUTE ONLY ON = ival
> 
>     (Optional) The ID of the only node to actually execute the script.
>     This option causes the script to be propagated by all nodes but
>     executed only by one. The default is to execute the script on all
>     nodes that are subscribed to the set.
> 
> 
> In my experience this property is not working correctly, and here's the 
> proof ("tiuhti" is origin and "viuhti" subscriber):
> 
> slony1 at tiuhti:~$ psql -d cldb -c "CREATE TABLE testtable (id int)" -h tiuhti
> CREATE TABLE
> slony1 at tiuhti:~$ psql -d cldb -c "CREATE TABLE testtable (id int)" -h viuhti
> CREATE TABLE
> 
> slony1 at tiuhti:~$ cat drop_table_testtable.sql
> DROP TABLE testtable;
> 
> slony1 at tiuhti:~$ cat droptest.slonik
> #!/usr/bin/slonik
> 
> CLUSTER NAME=climate;
> 
> NODE 1 ADMIN CONNINFO = 'dbname=cldb host=tiuhti user=slony1';
> NODE 2 ADMIN CONNINFO = 'dbname=cldb host=viuhti user=slony1';
> 
> EXECUTE SCRIPT (
>         SET ID = 1,
>         FILENAME = '/home/slony1/drop_table_testtable.sql',
>         EVENT NODE = 1,
>         EXECUTE ONLY ON = 2
> );
> 
> slony1 at tiuhti:~$ slonik droptest.slonik
> DDL script consisting of 1 SQL statements
> DDL Statement 0: (0,21) [DROP TABLE testtable;]
> Submit DDL Event to subscribers...
> DDL on origin - PGRES_TUPLES_OK
> 
> slony1 at tiuhti:~$ psql -d cldb -c "\d testtable" -h viuhti
> Did not find any relation named "testtable".
> 
> This is what I expected, but
> 
> slony1 at tiuhti:~$ psql -d cldb -c "\d testtable" -h tiuhti
> Did not find any relation named "testtable".
> 
> Wooah - the script dropped table testtable from both nodes although I 
> specified the "execute only on" -option. Is there something I'm missing 
> or is there a bug?
> 
> Regards
> 
> MP

The other issue with DDL scripts is that they do not honor SET
subscription members; certain portions of the sequence of events during
a DDL execute attempt actions on nodes not part of the affected SET.

http://lists.slony.info/pipermail/slony1-general/2007-January/005687.html

If we are examining the execute only portion of the code, perhaps we
could also check the SET parameters ...