Actually, in practice I've discovered that one almost never needs to
use a generic EXECUTE SCRIPT to apply ALTER TABLE statements. Wonder
if anyone else might be interested in the rules that I derived.

E.g. 

Add column can always be done without slony help.

Drop column depends upon the circumstances: if you you have foreign
key constraints on the table, you might be forced to use EXECUTE
SCRIPT but limited to the slave nodes, where the lock situation
usually is not an issue.

The basic property is "row compatibility". As long rows from the
master are compatible to the table description on the slaves, no
problems occur.

E.g.:

alter table TestTable add xxx text not null;

Assuming I've got dbmaster and dbslave, you do now:

psql -h dbslave -c "alter table testtable add xxx text not null default '';"
psql -h dbmaster -c "alter table testtable add xxx text not null default '';"

Now you can change drop the default if you dislike it.

Andreas

* Steve Singer <ssinger_pg at sympatico.ca> [061209 01:42]:
> 
> 
> This sort of starts up where the discussion at
> http://gborg.postgresql.org/pipermail/slony1-general/2006-July/004666.html
> left off.
> 
> There are a lot of situations where needing to obtain exclusive locks an all 
> tables in every replication set is really inconvenient. Much more so than 
> the DDL changes would be if they were done on a node without any 
> replication. Sometimes DDL changes don't require downtown of the 
> application, particularly if done carefully.  Add slony into the mix and 
> this changes.
> 
> 
> Ideally Slony would take a set of DDL statements 'figure out' what tables 
> will be locked in executing the DDL get those locks on all the nodes make 
> perform the DDL on each node and release the locks.  The above sequence 
> might not quite be right, I haven't thought about it in enough detail.
> 
> I don't think  there is a to 'figure out' from outside the backend 
> what locks are needed, would it even be possible to add an SPI function that 
> returned this information? If so how far would this go to helping things? 
> Are there other uses for this type of thing outside of replication?
> 
> 
> If we can't solve the problem in the general case for all DDL situations do 
> we want to consider ways to make some DDL situations easier.  For example
> 
> - Adding a column to a single table
> -Removing a column from a table
> -Changing table permissions
> 
> These would normally only require a lock on one table even adding a foreign 
> key to a replicated table could probably be done with a lot less locking 
> than the current EXECUTE SCRIPT.
> 
> 
> One option is to pass to execute script a list of tables that will need to 
> be locked. This would require the DBA to know what they are doing, but how 
> often would locks be required on tables other than the one being altered or 
> the one the foreign key references?
> 
> 
> Thoughts?
> 
> Steve Singer
> 
> 
> 
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general