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