On 1/15/07, Andrew Sullivan <ajs at crankycanuck.ca> wrote:
> On Fri, Jan 12, 2007 at 07:46:43AM -0500, Steve Singer wrote:
> >     Actually, as of version 1.1.5 and later, this is NOT TRUE. The danger of
> >     someone making DDL changes that crosses replication sets seems
> >     sufficiently palpable that slon(1) has been changed to lock ALL
> >     replicated tables,whether they are in the specified replication set or
> >     not.
>
> By the way, this has always struck me as a terrible hack.  What would
> be better, I think, is for there to be some dependency information
> about SETs, so that we had information on what can be properly called
> logically-complete sets, and information on what can be called
> partial sets (which are SETs for the purposes of Slony
> administration).
>
> It ought to be possible not to lock sets that are logically disjoint
> from one another.  It isn't now, and the quick and dirty answer of
> locking all sets is probably safer than what went before.  That
> doesn't make it ideal.  I know you had a v1 proposal for how to make
> this less painful.  I was thinking that what would be nice is an
> additional way to give hints to the system so that an administrator
> could group tables logically even if the database doesn't have
> constraints that are already imposing such rules.
>

My impression is that the major problem is with foreign keys across
sets.  Lots of DDL does not like the re-parented triggers and need to
have them restored.  A half-working foreign key still causes problems
which requires locking all the tables in a connected group.

I wonder if this can be fixed in PostgreSQL 8.2.  That version allows
disabling and enabling triggers.  There may be problems with a foreign
key half-working with some triggers disabled and some enabled.  It
might be better to leave the triggers disabled on the subscribers.  I
also ran into some bugs with the trigger disabling not working in some
cases.

 - Ian