Thread

1. Re: Small SSI issues

   Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-06-12T14:59:42Z

   > Heikki Linnakangas  wrote:
   > On 10.06.2011 18:05, Kevin Grittner wrote:
   >> Heikki Linnakangas wrote:
   >>> o There is no safeguard against actually wrapping around the
   >>> SLRU, just the warning
   >>
   >> Any thoughts on what we should do instead? If someone holds open a
   >> transaction long enough to burn through a billion transaction IDs
   >> (or possibly less if someone uses a smaller BLCKSZ), should we
   >> generate a FATAL error?
   > 
   > FATAL is a bit harsh, ERROR seems more appropriate.
    
   If we don't cancel the long-running transaction, don't we continue to
   have a problem?
    
   >> Do checks such as that argue for keeping the volatile flag, or do
   >> you think we can drop it if we make those changes? (That would
   >> also allow dropping a number of casts which exist just to avoid
   >> warnings.)
   > 
   > I believe we can drop it, I'll double-check.
    
   I see you committed a patch for this, but there were some casts which
   become unnecessary with that change that you missed.  Patch attached
   to clean up the ones I could spot.
    
   -Kevin
   
   
   

2. Re: Small SSI issues

   Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2011-06-12T20:01:10Z

   On 12.06.2011 17:59, Kevin Grittner wrote:
   >> Heikki Linnakangas  wrote:
   >> On 10.06.2011 18:05, Kevin Grittner wrote:
   >>> Heikki Linnakangas wrote:
   >>>> o There is no safeguard against actually wrapping around the
   >>>> SLRU, just the warning
   >>>
   >>> Any thoughts on what we should do instead? If someone holds open a
   >>> transaction long enough to burn through a billion transaction IDs
   >>> (or possibly less if someone uses a smaller BLCKSZ), should we
   >>> generate a FATAL error?
   >>
   >> FATAL is a bit harsh, ERROR seems more appropriate.
   >
   > If we don't cancel the long-running transaction, don't we continue to
   > have a problem?
   
   Yes, but ERROR is enough to kill the transaction. Unless it's in a 
   subtransaction, I guess. But anyway, there's no guarantee that the 
   long-running transaction will hit the problem first, or at all. You're 
   much more likely to kill an innocent new transaction that tries to 
   acquire its first locks, than an old long-running transaction that's 
   been running for a while already, probably idle doing nothing, or doing 
   a long seqscan on a large table with the whole table locked already.
   
   > I see you committed a patch for this, but there were some casts which
   > become unnecessary with that change that you missed.  Patch attached
   > to clean up the ones I could spot.
   
   Ah, thanks, applied. I didn't realize those were also only needed 
   because of the volatile qualifier.
   
   -- 
      Heikki Linnakangas
      EnterpriseDB   http://www.enterprisedb.com