List:Falcon Storage Engine« Previous MessageNext Message »
From:Philip Stoev Date:October 30 2008 8:22am
Subject:Re: Unthawable
View as plain text  
The server has some idle timeouts on the network level that will kill a 
completely idle connection after a few days, but those can easily be 
circumvented by sending select 1 over the wire.

To the best of my knowledge, Falcon and the server do not have any definite 
transaction-level timeouts or limits. I believe Jim's opinion is that if you 
have given access to somebody to your database servers, you deserve 
everything that will happen.

Philip Stoev

----- Original Message ----- 
From: "Lars-Erik Bjørk" <Lars-Erik.Bjork@stripped>
To: "Kevin Lewis" <Kevin.Lewis@stripped>
Cc: "Philip Stoev" <pstoev@stripped>; <falcon@stripped>
Sent: Thursday, October 30, 2008 9:17 AM
Subject: Re: Unthawable


Just a small question on the side ...

Do we abort transactions that have been idle for a certain period of
time to avoid a malicious user keeping transactions open in order to
fill up our disks?


/Lars-Erik

On Oct 30, 2008, at 1:55 AM, Kevin Lewis wrote:

> Phillip, every database system I know suffers from this problem that  you 
> cannot get rid of old parts of the serial log until the old  parts do not 
> contain anything from a committed transaction that is  not yet on disk in 
> page form.  Pervasive.SQL uses small 500Kb files  that keep adding up and 
> filling up the disk.  After the checkpoint,  the old ones can be deleted.
>
> We have the same problem, except we have only two files at a time.   It is 
> always up to the DBA or application designer to try to  optimize the 
> database and queries in a way that transactions do not  stay open for long 
> enough that the serial log will fill up the disk.
>
> I think Ann's comment is referring to the likelihood that chilled  records 
> will need to be deleted.  Yesterday, I repeated and debugged  (a little) 
> the current issue that Chris is seeing with unthawable  records. currently 
> tracked by Bug#39696)  We only see it using your  Gentest and 
> falcon-record-chill-threshold=4Kb or less.  Sometimes,  during this test 
> the same record version will chill and thaw several  times.  It is a 
> wonderful stress test.  Even though it is not likely  to see in the real 
> world, given enough time, what can happen, WILL  HAPPEN!
>
> Kevin
>
> Philip Stoev wrote:
>>>> Philip's cases are valuable tests, but not typical usage...  With
>>>> reasonable settings, chills will happen only during loads and mass
>>>> inserts.  The chances of modifying or deleting a record that's been
>>>> chilled are small, and the chances of having a multi-level modify /
>>>> chill / delete cycle are lower still.
>> Please find below an email from Kevin on another thread that  describes a 
>> potential chill/thaw/backlogging scenario that is not a  load or a mass 
>> insert -- attempting to generate a report by making  multiple passes 
>> through the entire data while writing intermediate  values in a summary 
>> table. If you decide to mark the start of your  execution by inserting a 
>> timestamp in some log table, your  transaction has become an update one 
>> and thus the serial log will  grow and the memory will fill up with old 
>> record versions.
>> Philip Stoev
>> ----- Original Message ----- From: "Kevin Lewis"  <Kevin.Lewis@stripped>
>> To: "Ingo Strüwing" <Ingo.Struewing@stripped>
>> Cc: "Øystein Grøvlen" <Oystein.Grovlen@stripped>;
> "'dev-backup'" 
>> <dev-backup@stripped
>> >; <falcon-private@stripped>
>> Sent: Wednesday, October 29, 2008 9:28 PM
>> Subject: Re: Restore makes ongoing transactions see empty tables
>>> A single transaction may make a couple passes through a table  summing 
>>> up certain columns for certain criteria.  We do not want  that data to 
>>> change in the middle of that transaction, for  example, between pass one 
>>> and pass two.  Currently, a table will  be truncated and then the 
>>> restored data will get replaced within a  new transaction.  The truncate 
>>> will be seen immediately by the  existing transaction, but the restored 
>>> data, being transactional,  will not be seen.
>
> -- 
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: 
> http://lists.mysql.com/falcon?unsub=1
>


Thread
UnthawableKevin Lewis25 Oct
  • Re: UnthawableJim Starkey25 Oct
  • Re: UnthawablePhilip Stoev29 Oct
    • Re: UnthawableKevin Lewis30 Oct
      • Re: UnthawableLars-Erik Bjørk30 Oct
    • Re: UnthawableAnn W. Harrison30 Oct
  • Re: UnthawablePhilip Stoev30 Oct
    • Re: UnthawableKevin Lewis30 Oct
      • Re: UnthawableHakan Kuecuekyilmaz30 Oct
      • Re: UnthawableJames Day31 Oct
Re: UnthawableKevin Lewis27 Oct
  • Re: UnthawableAnn W. Harrison27 Oct
  • Re: UnthawableJim Starkey27 Oct