Christopher Browne cbbrowne
Fri Feb 24 15:38:35 PST 2006
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.

- 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
:-).



More information about the Slony1-general mailing list