Andrew Sullivan wrote:
> On Tue, Mar 28, 2006 at 02:41:59PM -0500, Christopher Browne wrote:
>   
>> If I hear nothing, I expect I'll go with "option #1."  In principle,
>> #3 is the "cleanest," but it's definitely the most work.
>>     
>
> I'm uncomfortable with option 1: this seems like a much stronger lock
> requirement than I think we originally anticipated.  At the very
> least, it seems like it causes a requirement to be very careful in
> building your replication sets -- more careful than I think most
> users are willing to tolerate.
>
> A
>
>   
There's something of a "two way street" there...

In fact, I don't think there's any way you can't "not be very careful in
building your replication sets" here...

There are two contexts for it:

1.  The "locking then opening up all tables for modification" approach
amounts to Slony-I being "extra careful;" it means that Slony-I tries to
make all the tables "clean" for the duration of time when you're running
DDL on the node.

Jan validly points out that if we *don't* lock/fix all of the tables,
then the DDL will be running against a partially corrupted system catalog.

2.  Supposing we lock/fix only the one set's worth of tables, then there
is an unstated additional requirement, namely that you need to be extra
special careful in building your DDL to ensure that it only touches
tables in one replication set.

And there is still the (previously unstated) risk that must be taken on,
namely that the DDL runs against a partially corrupted system catalog.

We can shift the "extra care" around a little bit.  It doesn't go away
at all.