> No. A while back we decided to extend the locking (and fixing the system 
> catalog screwups) to all tables in all sets. Otherwise it is impossible 
> to have one script alter tables in more than one set, and it is 
> extremely dangerous if there are referential integrity constraints 
> across sets.

>From deadlock POV that's still not enough as there could be parent/child
tables which are not replicated at all (not that it makes too much sense
to do that).

> The thing I don't understand is how can this sort of schema changes be 
> required in the middle of the day without the need to shutdown and 
> upgrade the application at the same time?

If you carefully do your upgrade scripts, it can work out just fine. I
have in this very moment a script running which prepares our next
application software upgrade on the DB side... and the system is fully
working.

The trick is to make the schema changes in a few steps:
1) add new structures in a way it won't conflict with old structures,
and the application can work with both the old and new version on this
intermediary structure;
2) make a short downtime for the actual software upgrade, combined with
any non-compatible DB change, which BTW can be restricted to simple
property changes to mark the data that it should only be used by the new
version if properly designed;
3) remove the old unused structures;

This is not always simple to achieve, but can be done for almost all
changes you can imagine, even for things which need changing the data
itself. For those changes step 1 is divided in:
 - strictly structural changes, which should be fast but take exclusive
lock on the tables;
 - data migration: set default values, migrate old data to new form:
this we usually do in chunks, as it takes a long time but takes only
shared locks;

For real complex scenarios sometimes multiple structural and data
migration steps are needed to achieve the goal of upgrade while running.
But I can tell you it can be done.

Cheers,
Csaba.