From: Lars-Erik Bjørk Date: October 30 2008 8:17am Subject: Re: Unthawable List-Archive: http://lists.mysql.com/falcon/113 Message-Id: <5585BFB8-4BF8-4836-9AC8-648081741715@sun.com> MIME-Version: 1.0 Content-Type: text/plain; delsp=yes; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Just a small question on the side ... Do we abort transactions that have been idle for a certain period of = =20 time to avoid a malicious user keeping transactions open in order to = =20 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 tha= t =20 > you cannot get rid of old parts of the serial log until the old = =20 > parts do not contain anything from a committed transaction that is = =20 > not yet on disk in page form. Pervasive.SQL uses small 500Kb files= =20 > that keep adding up and filling up the disk. After the checkpoint,= =20 > the old ones can be deleted. > > We have the same problem, except we have only two files at a time. = =20 > It is always up to the DBA or application designer to try to =20 > optimize the database and queries in a way that transactions do not= =20 > 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 = =20 > records will need to be deleted. Yesterday, I repeated and debugge= d =20 > (a little) the current issue that Chris is seeing with unthawable = =20 > records. currently tracked by Bug#39696) We only see it using your= =20 > Gentest and falcon-record-chill-threshold=3D4Kb or less. Sometimes= , =20 > during this test the same record version will chill and thaw severa= l =20 > times. It is a wonderful stress test. Even though it is not likel= y =20 > to see in the real world, given enough time, what can happen, WILL = =20 > HAPPEN! > > Kevin > > Philip Stoev wrote: >>>> Philip's cases are valuable tests, but not typical usage... Wit= h >>>> reasonable settings, chills will happen only during loads and ma= ss >>>> inserts. The chances of modifying or deleting a record that's b= een >>>> chilled are small, and the chances of having a multi-level modif= y / >>>> chill / delete cycle are lower still. >> Please find below an email from Kevin on another thread that =20 >> describes a potential chill/thaw/backlogging scenario that is not = a =20 >> load or a mass insert -- attempting to generate a report by making= =20 >> multiple passes through the entire data while writing intermediate= =20 >> values in a summary table. If you decide to mark the start of your= =20 >> execution by inserting a timestamp in some log table, your =20 >> transaction has become an update one and thus the serial log will = =20 >> grow and the memory will fill up with old record versions. >> Philip Stoev >> ----- Original Message ----- From: "Kevin Lewis" =20 >> >> To: "Ingo Str=FCwing" >> Cc: "=D8ystein Gr=F8vlen" ; "'dev-backup'= " > >; >> 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 = =20 >>> summing up certain columns for certain criteria. We do not want = =20 >>> that data to change in the middle of that transaction, for =20 >>> example, between pass one and pass two. Currently, a table will = =20 >>> be truncated and then the restored data will get replaced within = a =20 >>> new transaction. The truncate will be seen immediately by the = =20 >>> existing transaction, but the restored data, being transactional,= =20 >>> will not be seen. > > --=20 > Falcon Storage Engine Mailing List > For list archives: http://lists.mysql.com/falcon > To unsubscribe: http://lists.mysql.com/falcon?unsub=3Dlars-erik.= bjork@stripped >