On Wed, Aug 18, 2010 at 7:39 PM, Selena Deckelmann
<selenamarie at gmail.com> wrote:
> Hi!
>
> Steve & Chris, please meet Robert!  Robert hacks on stuff for
> Canonical, and is interested in handling DDL replication more nicely.
>
> In particular, this is something that is concerning:
>
> "Note: 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 has been changed to lock ALL
> replicated tables, whether they are in the specified replication set
> or not."
>
> So -- questions are:
>
> * Can we reasonably disable this and restrict locking to a particular
> replication set, allowing savvy DBAs to employ the footgun when they
> really need it?
> * Is there an even more awesome possibility of extending Slony
> (possibly funded!) to manage locks more politely, and only lock
> relations that actually need to be locked?
>
> And I may have mis-stated Robert's questions, so I leave it to him to
> correct whatever I got wrong.

In version 2, the locking is exceedingly less restricting, to the
point of there being a possible problem :-(.
<http://bugs.slony.info/bugzilla/show_bug.cgi?id=137>

Steve, Jan Wieck, and I have been chatting about this over the last
couple weeks, which is where the comments on that bug #137 have come
from.  (And thus, there couldn't be a more ideal time for extra eyes
to be in on the conversation.)

Where Jan's leaning comes in the comment here:
------
To fix this, slonik needs to issue LOCK TABLE statements right after "begin;".
That way, it will wait until all conflicting transactions have committed before
generating its own snapshot.

We need new syntax to add this information to the EXECUTE SCRIPT command and it
will be the responsibility of the user to provide the list of tables to lock.
------

So, in 1.2, things are "too locked down," in 2.0, things are
"insufficiently locked down" (which I should observe we *THOUGHT* was
a feature, not noticing this particular downside), and it's a pretty
good time for there to be a conversation about how to handle this in
what's probably version 2.1.

I suggest taking this conversation over to the mailing list, probably
slony1-general (http://lists.slony.info/mailman/listinfo).

The "magical answer" would be to have an oracle (a computer science
notion of a possibly-nonexistent machine that can answer particular
questions) that would tell us what tables need to be locked in order
to run the DDL.  Unfortunately, since the DDL might include stored
procedures that can run arbitrary dynamic statements, this would need
to be a Magical Oracle indeed.

At any rate, this is a fine conversation to hold, and who does the
work is rather less important than that there be a meaningful
discussion, ideally, on the mailing list, as that gets the right sorts
of eyes on it.
--
http://linuxfinances.info/info/linuxdistributions.html