On 5/13/2014 6:08 AM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> If a record has uncommitted head version created by active transaction and some garbage
> in backversions "tail", can anyone (background GC thread, sweep or parallel transaction)
> wipe this garbage from the tail while the transaction is still active?
> I can't understand why list_staying() is so picky: it scans for every next version from
> the beginning which raise its complexity to O(N^2).
>
Index garbage collection is a very thorny problem. The original version
predates threads in any operating system. Garbage collection occurred
only when a record was visited. Garbage collection of an uncommitted
record version was highly problematic since it was impossible to know
whether the current version of the record would be going or staying,
hence impossible in some cases to know whether an unreachable record
version had an index key that could be garbage collected or not.
We introduced threading in version 3. It was a nightmare. Virtually all
of the operating systems that supported threading were buggy as hell (I
wrote our own threading package for VMS, which didn't yet support
threads). Sun's threading examples didn't even compile. A infrequent
hang on Apollo was finally diagnosed as an "unfixable" design flaw when
a signal arriving during a thread switch would be dropped on the floor,
requiring that all signal based mechanisms in Interbase be rewritten to
use threads. Revisiting garbage collection just wasn't in the cards.
For most of its existence, Interbase and Firebird have only had one
thread active in the engine. This kept synchronization of garbage
collection and record update, which kept garbage collection simple and
sane. Fine grain multi-threading, however, opens a major can of worms.
My subsequent database systems do all garbage collection other than
record backout in a dedicated garbage collect thread. Worker thread
note when garbage collection is in order for a record and post it for
the garbage collector to take up on next cycle.
I don't know the current state of Firebird, but the idea of trying to
synchronize cooperative (i.e. worker thread) and dedicated thread
garbage collection is something I wouldn't want to take on.
However, in direct answer to your question, let ask another: How to do
garbage collect old record versions without visiting them? Any how can
you even tell if there are collectable old versions without traversing
the live versions first?
There are probably lots of things that could be done to improve garbage
collection. The one I think most fruitful is ability to garbage collect
unreachable intermediate records between active versions at the front of
a chain and older versions accessible only by very long running
transactions so that very long running transaction don't impede all
garbage collection.
|
