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
>
