List:Falcon Storage Engine« Previous MessageNext Message »
From:John Embretsen Date:May 15 2009 8:55am
Subject:Weekly Falcon bazaar merge
View as plain text  
Hi falconers,

I just finished the weekly merge of our bazaar branches

   mysql-6.0 --> mysql-6.0-falcon --> mysql-6.0-falcon-team

   mysql-6.0-falcon-team --> mysql-6.0-falcon

Commit comments from merged revisions are attached to this E-mail.

As always, please test your code tree for unusual problems like compile
errors or the like.

The latest merge will appear in the public falcon branch on Launchpad
within a couple of hours. You can create your own local branch from

bzr branch lp:~mysql/mysql-server/mysql-6.0-falcon


Cheers and happy compiling,

John H. Embretsen
QA Engineer, Sun Microsystems

Merged 8 revision(s):
revno: 2849
committer: Alexander Nozdrin 
branch nick: 6.0
timestamp: Wed 2009-05-13 07:25:49 +0400
  Fix default.conf
revno: 2848
committer: Luis Soares 
branch nick: 6.0-rpl
timestamp: Tue 2009-05-12 09:58:44 +0100
  merge: 6.0 --> 6.0-rpl
  manually resoved conflicts:
revno: 2847
committer: Luis Soares 
branch nick: 6.0-rpl
timestamp: Mon 2009-05-11 11:22:35 +0100
  BUG#44779: binlog.binlog_max_extension may be causing failure on next 
  test in PB
  Disabling test while conducting analysis.
revno: 2846
committer: He Zhenxing 
branch nick: 6.0-rpl
timestamp: Fri 2009-05-08 15:49:21 +0800
  BUG#44058 Possible semi-sync replication bugs
  Fix previous patch.
  Move thd_enter_cond/thd_exit_cond from plugin.h to replication.h
revno: 2845
committer: Luis Soares 
branch nick: 6.0-rpl
timestamp: Thu 2009-05-07 12:44:40 +0100
  merge: 6.0 --> 6.0-rpl
  conflicts resolved manually:
    Text conflict in .bzr-mysql/default.conf
    Text conflict in mysql-test/suite/rpl/t/disabled.def
revno: 2844
committer: Luis Soares 
branch nick: 6.0-rpl-b40045
timestamp: Wed 2009-04-29 17:48:59 +0100
  BUG#40045: Replication failure on RBR + no PK + UPDATE + integer key +
  char with no key
  Row based replication would break if updating a row and using a key
  for searching for the correct row to update. This was observed when
  using MyISAM storage engine on the slave. Since MyISAM does not
  provide partial row fetch (HA_PARTIAL_COLUMN_READ) , the comparison
  between the row fetched on the slave and the before image (BI)
  replicated from master would fail. This happened because the BI (which
  sometimes was only part of the row) would always be compared against a
  complete row.
  Furthermore, the read set mask was not being properly set in some cases
  when using keys (not unique nor primary) which would lead to partial 
  row matches, thence changes might end up in the wrong row.
  This patch addresses this by changing the record_compare function for
  taking into consideration the fields set on the readset and the engine
  used on the slave. Furthermore, it also moves the mark columns needed
  for update on the master so that read_set bitmap is always correct.
revno: 2843
committer: Andrei Elkin 
branch nick: 6.0-rpl-bug38716-restart_slave_kill_crashed
timestamp: Wed 2009-04-29 15:58:20 +0300
  merge from 6.0-rpl for a local bug branch
revno: 2842
committer: Andrei Elkin 
branch nick: 6.0-rpl-bug38716-restart_slave_kill_crashed
timestamp: Tue 2009-04-28 00:18:21 +0300
  Bug #38716 slave crashed after 'stop slave' during concurrent stop/start/reset
  Bug #44312  deadlock between IO thread and SLAVE START
  The issue in terminate_slave_threads() of bug#38716 was reproduced in a slighly
  different form. terminate_slave_threads() should not acquire run_lock when it's
  called from slave_thread()->start_slave_threads(); 
  that leads to an assertion on run_lock mutex.
  OTH, init_slave()->start_slave_threads() path requires terminate_slave_threads() to
  be invoked with skip_lock == false.
  No other crashes has been found using the regression stress test program.
  Another issues is a deadlock as described separately in Bug #44312.
  It was caused by grabbing two mutexes by IO thread and STARTing SLAVE thread in
  reverse order.
  terminate_slave_threads() does not request locking in start_slave_threads()
  when it's called from start_slave() and does it when it's called from init_slave();
  rotate_relay_log() does not acquire mi->run_lock which is safe. 
  The rli->inited is not guarded by this mutex, and locking of the mutex 
  in the function contradicts the safe pattern of locking with run_lock.

Merged 8 revisions from mysql-6.0-falcon-team:
revno: 2706
committer: John H. Embretsen 
branch nick: mysql-6.0-falcon-team-to-merge
timestamp: Fri 2009-05-15 09:20:04 +0200
  Merge: mysql-6.0 --> mysql-6.0-falcon --> mysql-6.0-falcon-team
    in preparation for merge mysql-6.0-falcon-team --> mysql-6.0-falcon

  .bzr-mysql/default.conf (tree name) adjusted.
revno: 2705
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Thu 2009-05-14 00:16:08 -0500
  Bug#44850 - Delete the member variable StorageTable::dataStream since it can point into, which can be
chilled while it exists.
  Instead, use local pointers that are protected by a CycleLock so that even if the
data.record  is chilled, that buffer will be accessable
until the next cycle.
  Fix Record::deleteData so that it works for chilled records.
  Also, fix Record::getDataMemUsage() so that it does not thaw.  That was an inadvertent
change from a recent patch.
revno: 2704
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Tue 2009-05-12 17:58:23 -0500
  Code Cleanup and compile warnings
  Fix the previous patch for Bug#43344 & Bug#44721 that made a call to
  from inside a thaw.  This caused a recursive loop and a stack overflow.
revno: 2703
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Tue 2009-05-12 10:27:23 -0500
revno: 2702
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Tue 2009-05-12 09:35:40 -0500
  Bug#43344 & Bug#44721
  Second patch (comprehensive) with review changes

  This series of changes closes many gaps in which a data buffer can get
  thawed and then re-chilled almost immediatly which can cause the use
  of a bad data buffer pointer.  For 44344, it makes the act of chilling
  and thawing records an atomic operation which uses CAS.  Each call to
  thaw returns a valid pointer to the buffer that was thawed so that it
  can be used during the current cycle as long as the caller has a

  Record.h, Record.cpp, RecordVersion.h & RecordVersion.cpp;

  The most significant change is that when a data buffer is chilled,
  it recieves the value (-1) and this happens atomically.
  Record::state == recChilled is no longer used.
  The pointer is now always read once, checked, and
  returned up the call stack to where it is used.

  hasRecord() is changed from an inline function to a virtual function
  for both Record and RecordVersion. hasRecord() and isChilled() are
  added so that the record can check data.record itself.

  setEncodedRecord() and thaw() return the pointer to the buffer
  that they just created and put into data.record so that the caller
  does not have to rely on that buffer being there later.

  getEncodedValue() uses the recordData pointer of the caller instead
  of getting it again from data.record.

  getAllocatedSize() is added so that the number of bytes in a buffer
  holding the record can be consistently known.  It is used in several

  chillData() is similar to and replaces deleteData() during

  isDeleted() is also added so that the common (state == recDeleted)
  check can be done by the record itself.  This is not fully
  implemented yet because we need to get away from the over-use of
  these state flags.  They are somewhat unreliable on multiple CPUs
  unless they are set with CAS.

  getRecordData() is also changed from an inline to a virtual function.

  findRecordData() is like getRecordData but without the thaw.  It is
  used in three places along the call stack for thawing a record to
  check if another thread has already thawed that record.  This is
  not likely now because of the use of syncThaw.  But syncThaw may
  no longer be necessary.

  isAllocated() is an inline function used about 6 times to determine
  if a pointer is real or not.

  SRLUpdateRecords.h & SRLUpdateRecords.cpp;

  thaw() returns the data buffer thawed in addition to the number of
  bytes reallocated.

  chill() is not sent the dataLength anymore since it calculates that

  SerialLog.h, SerialLog.cpp, transaction.h, transaction.cpp;

  Since the number of bytes chilled and thawed stored in the SerialLog
  and Transaction were being maintained but not used, I deleted those
  variables and code used to maintain them.  The number of allocated
  bytes associated with a Transaction is stored in totalRecorddata and
  is still maintained.

  Even though backlogging is not currently active, the choice whether
  to backlog any particular record needed to be enhanced.  Along with
  replacing hasRecord(false) with isChilled(), it should avoid
  backlogging record chains that do not start at the base record.
  That is checked with isSuperceded(). Also, backlogging should occur
  for deleted records as well as newly chilled records.
revno: 2701
committer: Kevin Lewis 
branch nick: mysql-6.0-falcon-team
timestamp: Fri 2009-05-08 13:37:39 -0500
  Code Cleanup
  Record.cpp;  Use addRef so that REC_HISTORY is saved.  Also use totalLength which was
already added up.
  Record.h; correct comment
  SRLBlobDelete.cpp;  Adjust spacing
  SRLUpdateRecords.cpp; Delete unneeded tabs.  Change unexpected condition for wrong page
number into an assert.  This should not happen.
  SerialLogFile.cpp; change inconsistent formatting.
  Table.cpp; Deleted both actions when wasLock is true.  state was alredy set to
recDeleted and this is not a correct place to set
decrement deletedRecords.  This would make this value < zero.  Then that possibility
was tested for at the bottom  of
Transaction::removeRecordNoLock(). I left the test in place, but deleted this mistake. 
The result of this, if it had not been tested for,
is just bad log reporting.
  Transaction.cpp;  Enhanced the LogXARecovery reporting to use TransID instead of a
transaction pointer and also display the SQL
revno: 2700
committer: Olav.Sandstaa
branch nick: falcon-dbug-fix
timestamp: Thu 2009-05-07 20:29:18 +0200
revno: 2699
committer: Olav.Sandstaa
branch nick: falcon-dbug-fix
timestamp: Wed 2009-05-06 21:40:24 +0200
  Fixed two DBUG traces to log the correct method name.

Weekly Falcon bazaar mergeJohn Embretsen15 May