From: Ann W. Harrison
Date: October 9 2008 9:24pm
Subject: Backlogs and Philip's dastardly tests
List-Archive: http://lists.mysql.com/falcon/26
Message-Id: <48EE7671.2020301@mysql.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 7BIT

Philip Stoev's test for backlogging has turned up a number of
interesting problems, some of which are easy, and some of which
are probably going to involve some further use of backlogging.

The first problem was a crash in SerialLog::getTableSpaceInfo.
You may wonder "what is the intersection between backlogging
and the serial log?"  The answer is that there should be none.
Nothing about the backlog goes through the serial log.  However,
the backlog is a degenerate tablespace with an id of -1. that
has exactly one section.

When a section is created, it checks to see if a section with
that id is in use in the tablespace where it's being created.
The serial log keeps tablespace information, including which
sections exist in which tablespaces.  However, -1 is not a legal
value for a tablespace id in the mind of the SerialLog leading
to accessing the space before a hash table and other bad results.

That's easy enough.  When Section goes to Dbb to find out about
the state of sections in that tablespace, Dbb checks for a
tablespace id of -1 and doesn't pass the call on to SerialLog.

The next problem is an assert that sometimes fails in
TABLE::backlogRecord.  For reasons not yet clear, the insert
of a backlog record fails, once in a while.

The most serious problem is that this test clearly demonstrates
that backlogging as we're now doing it, doesn't solve the problem
of running out of record cache.  Currently Falcon backlogs records
after a record chill cycle.  If the chill threshold is high or
transactions are short, nothing goes to the backlog.  I'd like
to talk tomorrow morning about other points where records should
be moved to the backlog.


Cheers,


Ann