On 10/16/2006 9:53 AM, Andrew Sullivan wrote:
> On Mon, Oct 16, 2006 at 08:49:51AM -0400, Bill Moran wrote:
>> 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.
> 
> Well, the more I think about it, the more I think you could run this
> as a completely separate daemon.  You'd need knowledge of your
> application's database use, but that'd probably be a good thing
> anyway.  Then your daemon just takes a write lock on the tables
> you're really concerned about preventing a write in, and releases it
> when Slony catches up.  It's not a cheap solution, but for such a
> specialised case I think roll-your-own is the way to go anyway.

 From my point of view, only transactions that actually generate 
replication traffic are worth blocking. Why would you want to block a 
read-only transaction?

Now all transactions that generate replication traffic have something in 
common. They insert into sl_log_?, so locking that against inserts with 
a simple LOCK TABLE ought to be enough.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #