On 2/24/2006 6:38 PM, Christopher Browne wrote:

> Rod Taylor wrote:
> 
>>On Fri, 2006-02-24 at 17:22 -0500, Christopher Browne wrote:
>>  
>>
>>>Jan submitted an update for log switching (switch periodically between
>>>sl_log_1, sl_log_2, truncating the empty one), I have a patch for the
>>>EXECUTE SCRIPT bug, and Darcy submitted updates for improving
>>>interaction between Slony-I and pg_autovacuum. 
>>>    
>>>
>>
>>Slick.
>>
>>Will the sl_log_[12] truncation handle insanely long transactions? That
>>is, if Slony is supposed to switch log tables after 1 million
>>transactions, what happens if a single transaction crosses 2 million
>>transactions and is still active precluding either structure from being
>>truncated (or deleted from)?
>>
>>  
>>
> Just to be picky, the trouble is actually with 2 billion transactions...
> 
> Supposing you have a system *so* busy that you go through 2 billion
> transactions per week, but you also have a single transaction that runs
> for an entire week, that's the case that'll be troublesome.

I think Postgres itself will be pretty unhappy with this particular 
situation.


Jan

> 
> - The long running transaction will Cause Problems for any tables that
> are updated frequently because you'll have a week's worth of (billions
> of updates per week!!!) dead tuples not vacuuming out. 
> 
> - Up until 1.2, Slony-I would have keeled over, in that scenario,
> because pg_listener would have a zillion dead tuples in it.
> 
> - This case points to my paranoia about TRUNCATE (expressed this
> afternoon on IRC) having some merit... 
> 
> Jan, I think the case Rod describes is a case that makes it mandatory
> for logswitch_finish() to exit without truncating if it sees any locks
> outstanding on the sl_log_n table in question; you could have the
> situation where a long running transaction has 1M tuples, not yet
> committed, sitting in sl_log_1.  They aren't visible as being live
> tuples, but they are NOT dead...
> 
> I'm not certain what ultimately happens, now, with the "insanely long
> transactions" case (on an otherwise also-busy server).  We now have
> fewer (I'm not sure about "no") reasons for Slony-I to punish you for
> long running transactions (LRTs :-)), so a replicated DB might now
> survive traffic + LRT.
> 
> So I guess I'm not sure now :-).  I'm glad you brought this up; if
> several more people do a bit of wondering, we may come up with an answer
> :-).
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


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