List:Falcon Storage Engine« Previous Message
From:John Embretsen Date:July 30 2009 1:48pm
Subject:Re: Summerly Falcon bazaar merge
View as plain text  
John Embretsen wrote:

> Commit comments from the merged revisions are attached to this E-mail,
> along with a list of touched files.

Attached to _this_ E-mail, I mean... :)


-- 
John

 M  mysql-test/collections/mysql-6.0-falcon-team.weekly
 M  storage/falcon/Cache.cpp
 M  storage/falcon/Connection.cpp
 M  storage/falcon/Connection.h
 M  storage/falcon/DataPage.cpp
 M  storage/falcon/Dbb.cpp
 M  storage/falcon/Dbb.h
 M  storage/falcon/IO.cpp
 M  storage/falcon/Record.cpp
 M  storage/falcon/Record.h
 M  storage/falcon/RecordLeaf.cpp
 M  storage/falcon/RecordVersion.cpp
 M  storage/falcon/RecordVersion.h
 M  storage/falcon/SavePoint.cpp
 M  storage/falcon/SavePoint.h
 M  storage/falcon/StorageDatabase.cpp
 M  storage/falcon/StorageVersion.h
 M  storage/falcon/Synchronize.h
 M  storage/falcon/Table.cpp
 M  storage/falcon/Transaction.cpp
 M  storage/falcon/Transaction.h
All changes applied successfully.


Merged 12 revision(s):
------------------------------------------------------------
revno: 2762
committer: John H. Embretsen 
branch nick: mysql-6.0-falcon-team
timestamp: Thu 2009-07-30 10:09:40 +0200
message:
  Bump Falcon version in preparation for merge to public branch.
------------------------------------------------------------
revno: 2761
committer: John H. Embretsen 
branch nick: mysql-6.0-falcon-team
timestamp: Thu 2009-07-30 10:00:26 +0200
message:
  Bug#45331 - Follow-up change: Remove falcon_bug_22150-big from list of tests to be run
on weekly basis, because it causes 1800s timeouts on all but the fastest platforms in
PB2.
  A better solution (e.g. increase PB timeout for certain tests, or make the test ouput
something to std out regularly) should be developed later.
------------------------------------------------------------
revno: 2760 [merge]
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Tue 2009-07-28 10:53:09 -0500
message:
  merge
    ------------------------------------------------------------
    revno: 2758.1.1
    committer: Kevin Lewis 
    branch nick: mysql-6.0-falcon-team
    timestamp: Fri 2009-07-24 16:35:52 -0500
    message:
      Code Cleanup
------------------------------------------------------------
revno: 2759
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Mon 2009-07-27 10:36:30 -0500
message:
  Bug #46402 - Protect Transaction::findOldestInActiveList() with a shared lock on
Transaction::activeTransactions.
------------------------------------------------------------
revno: 2758
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Fri 2009-07-24 12:56:07 -0500
message:
  Bug#46324 - Crash in log statement is avoided by checking the vilidity of connection
pointer and connection->currentStatement.
------------------------------------------------------------
revno: 2757
committer: John H. Embretsen 
branch nick: build-mysql-6.0-falcon-suites
timestamp: Fri 2009-07-17 15:38:49 +0200
message:
  Bug#45331: Add falcon_bug_22150-big and falcon_bug_36294-big to list of test to run on
weekly basis in PB2. These tests will probably fail due to bug 45845.
------------------------------------------------------------
revno: 2756
committer: John H. Embretsen 
branch nick: build-mysql-6.0-falcon-suites
timestamp: Fri 2009-07-17 14:22:55 +0200
message:
  Follow-up patch for Bug#45331 - Tests are not run on the weekly-6.0-falcon-team tree.
  This patch reverts revid john.embretsen-20090625165940-3hbf6y9a73x4ter2 which modified
PB2 config to run all big-tests in the falcon suite instead of just the unproblematic
ones.
  
  It turns out that PB2 itself times out the tests after some time, even if MTR does not.
  According to bug 39969 there is a timeout that kicks in if the test does not ouput
anything within 1800 seconds.
  
  Typical output in this case is:
  
  "[PB2] script did not complete, timeout?"
  
  With this patch, we go back to avoid running the tests which take "too long" to run, see
comments to Bug#45331 for details.
------------------------------------------------------------
revno: 2755
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Tue 2009-07-14 09:09:58 -0500
message:
  Bug#45746 - Gopher thread gets error 305.
  The previous patch for this bug made it highly unlikely for the
  gopher thread to get error 305-out-of-record-cache.  But it is
  still possible since thawAll() still may need to muck with the 
  record cache.
  
  So this patch makes the gopher thread retry the attempt to 
  allocate a record another 10 time.  Client threads which also 
  get this error will not retry so they will probably rollback 
  and free some memory.  In thawAll(), the gopher will also give 
  up if the transaction gets too old while this is happening.
  
  Then after 10 tries, which should take more than 22.5 seconds,
  The gopher will just give up trying to thaw that record, 
  which may never be needed anyway.  If it is needed, the client 
  thread must be able to recognize an unthawable record.
  
  If thawAll does not thaw a record, it will remain thawable
  from the serial log until the serial log toggles so that the 
  virtual offset is no longer around.  So this patch uses two 
  new indicators to identify an unthawable record.  The first is
  a new state called recBuried which indicates that the record 
  version has been replaced in the page.  This is now set in 
  thawAll(), during transaction completion.  Then later, if a 
  'buried' record cannot be thawed from the serial log, 
  RecordVersion::thaw() does not attempt to thaw it from the 
  page.  It just marks it as unthawable by setting 
  Record::data.record = recordDataIsFreed.
  
  Then the client thread in fetchVersion() must throw an error 
  indicating that a visible record cannot be thawed.
------------------------------------------------------------
revno: 2754 [merge]
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Sun 2009-07-12 22:24:23 -0500
message:
  merge
    ------------------------------------------------------------
    revno: 2752.1.1
    committer: Olav Sandstaa 
    branch nick: falcon-bug45301-test
    timestamp: Fri 2009-07-10 14:52:00 +0200
    message:
      Fix for Bug#45301 Recovery crash due to fetched page marked free in PIP
      
      This crash occured during recovery due to at the time of the crash the main data
page for a record had
      written to the data base file while the PIP and the newly allocatedoverflow page for
the record had not 
      been written. The corresponding SRLOverflowPages log record was likely not flushed
to the serial log.
      This situation happened likely due to MySQL being killed during a Falcon check
point.
      
      This is now handled by extending the IO::readPage() so that an exception is thrown
in the cases there
      is reads beyond end-of-file during recovery. This exception is caught in
DataPage::deleteOverflowPages.
      If it happens during recovery, DataPage::deleteOverflowPages will handle the
exception by marking the
      overflow page as free in the Page Inventory Page.
      
      Note that if there are more than one overflow page for this record we might have
permanent loss of a few
      blocks in the database.
      
      The patch also fixes an missing handling of exceptions in Cache::fetchPage() where
an IO excecption would
      lead to a BDB having a use count that never got released and which resulted in a
crash during shutdown.
------------------------------------------------------------
revno: 2753
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Wed 2009-07-08 15:05:22 -0500
message:
  Bug#45746 - Gopher thread gets error 305.
  Transaction::thawAll was added for 44946 but it was too intrusive.
  It required a full thaw of all records in the transaction.  This
  patch limits thawAll to only those records that have already been
  superceded by a newer change at 'complete time' when thawAll is 
  called.  
  
  Also, RecordVersion::superceded is converted to 
  RecordVersion::base and made more reliable by updating it in
  RecordLeaf::store.

Thread
Summerly Falcon bazaar mergeJohn Embretsen30 Jul
  • Re: Summerly Falcon bazaar mergeJohn Embretsen30 Jul