In response to Andrew Sullivan <ajs at crankycanuck.ca>:

> On Sun, Oct 15, 2006 at 02:42:04PM -0400, Bill Moran wrote:
> > transactions behind.  When the backlog got to 50, the master would block
> > on new transactions until the slaves caught up.
> 
> [. . .]
> 
> > I don't know how difficult this would be to implement, it's just a
> > thought.
> 
> I suppose you could do it by taking an exclusive lock (well, probably
> a write lock would be enough) on every database object; the Slony
> user already has to be a superuser, so it would have the permissions
> necessary.  It'd have to be somewhat fuzzy (because you can't control
> the transactions that perform BEGIN before you try to take your
> lock), but it'd work.  I really question, though, whether it'd be a
> good idea: the whole point of async replication is that what happens
> on the replica doesn't affect transactions on the origin.  Wouldn't
> two-phase commit be better for this?

I can imagine some use-case scenarios for this, although it's admittedly
a niche.

The problem with 2-phase commit is that performance across a WAN suffers
mightily.  With Slony, the application that's using the master can
operate at pretty much full speed, of course, that's the benefit of
asynchronous replication.  However, in scenarios where 99% of the time
the bandwidth is sufficient to keep the slave up to speed, Slony will
perform as a "near-synchronous" system, in my experience.

So, imagine a use case with the backup system somewhere across a WAN,
with high bandwidth-delay.  The business case has a requirement for the
reliability of synchronous replication, but also requires the performance
of asynchronous.  (Isn't this what everyone really wants anyway?  The
best of both worlds.)  Slony with a sync limit might just be a good
compromise.  Under normal loads, the system stays nearly synchronous
but performs as if there's a single primary.  Under heavy loads, the
system degrades "gracefully" to acting more like a synchronous system
would over a WAN -- it's runs at the maximum speed that it can across
the WAN while still keeping the two systems from getting too far out
of sync.

I can imagine a lot of possible problems with this, but it's an interesting
idea (to me, at least).  I expect it would need a lot of testing to see
if it's actually viable.

-- 
Bill Moran
Collaborative Fusion Inc.