List:Falcon Storage Engine« Previous MessageNext Message »
From:John H. Embretsen Date:May 20 2009 5:11pm
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

and

    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 such as 
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
launchpad:

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

(see https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-falcon)


Cheers and happy compiling,

-- 
John H. Embretsen
QA Engineer, Sun Microsystems

Merged 1 revision from mysql-6.0-falcon-team:
------------------------------------------------------------
revno: 2707
committer: Olav Sandstaa 
branch nick: falcon-bug44292
timestamp: Mon 2009-05-18 11:42:26 +0200
message:
  Fix for Bug#44292 falcon_bug_34351_C fails with assertion (false) in file
RecordLocatorPage.cpp
  
  This crash was caused by an inconsistency in the RecordLocator
  page. In some situations the maxLine value was not updates when
  inserting new space management slots. This could cause later updates
  to the record locator page to introduce inconsistencies in the record
  index.
  
  This patch changes RecordLocatorPage::setIndexSlot() to handle
  situations where the slot to be inserted has a slot number larger than
  the maxLine value. Before this patch if a slot number that was larger
  than the current maxLine value was inserted, the maxLine value was not
  updated accordingly. The fix is to update the maxLine value based on
  the inserted slot number.

Merged 20 revisions from mysql-6.0:
------------------------------------------------------------
revno: 2778
committer: Alexander Nozdrin 
branch nick: 6.0-rt
timestamp: Sat 2009-05-16 12:36:58 +0400
message:
  Merge from 6.0
------------------------------------------------------------
revno: 2777
committer: Dmitry Lenev 
branch nick: mysql-6.0-bg44738
timestamp: Fri 2009-05-15 12:00:35 +0400
message:
  Fix for bug #44738 "fill_schema_table_from_frm() opens tables without
  lowercasing table name".
  
  In lower_case_table_names > 0 mode some queries to I_S left entries
  with incorrect key in table definition cache. This wasted memory and
  in combination with similar problem in CREATE TABLE (which also has 
  peeked into table definition cache using non-normalized key) led to 
  to spurious ER_TABLE_EXISTS_ERROR errors when one tried to create a 
  table with the same name as a previously existing but dropped table
  (assuming that table name contained characters in upper case).
  
  This problem occured due to fact that fill_schema_table_from_frm()
  was not properly normalizing (lowercasing) database and table names 
  which it used for lookups in table definition cache.
  
  This fix adds proper normalization to this function. It also solves
  similar problem in CREATE TABLE's code by ensuring that it uses 
  properly normalized version of table name when it peeks into table
  definition cache instead of non-normalized one.
------------------------------------------------------------
revno: 2776
committer: Jon Olav Hauglid 
branch nick: mysql-6.0-runtime-bug21793
timestamp: Thu 2009-05-14 16:33:44 +0200
message:
  manual merge
------------------------------------------------------------
revno: 2775
committer: Jon Olav Hauglid 
branch nick: mysql-6.0-runtime-bug21793
timestamp: Thu 2009-05-14 16:27:03 +0200
message:
  Bug #21793 Missing CF_CHANGES_DATA and CF_STATUS_COMMAND for 
  handful of commands
        
  CF_CHANGES_DATA and CF_STATUS_COMMAND flags added to the 
  commands mentioned in the bug description. With the following
  two exceptions: 
  
  1) 4 commands do not exist: 
  SQLCOM_RENAME_DB
  SQLCOM_LOAD_MASTER_DATA
  SQLCOM_LOAD_MASTER_TABLE
  SQLCOM_SHOW_COLUMN_TYPES
  
  2) All SQLCOM_SHOW_* commands already had CF_STATUS_COMMAND,
  leaving only SQLCOM_BINLOG_BASE64_EVENT.
  
  Further, check_prepared_statement() in sql_prepare.cc has been
  simplified by taking advantage of the CF_STATUS_COMMAND flag.
  
  Note that no test case has been added.
------------------------------------------------------------
revno: 2774
committer: Davi Arnaut 
branch nick: mysql-6.0-runtime
timestamp: Mon 2009-05-11 14:58:07 -0300
message:
  Merge from 6.0 main.
------------------------------------------------------------
revno: 2773
committer: Jon Olav Hauglid 
branch nick: mysql-6.0-runtime-bugged
timestamp: Fri 2009-05-08 16:11:05 +0200
message:
  manual merge
------------------------------------------------------------
revno: 2772
committer: Jon Olav Hauglid 
branch nick: mysql-6.0-runtime-bugged
timestamp: Fri 2009-05-08 15:34:08 +0200
message:
  Bug #31293 create logfile group/tablespace returns OK with warning 
  when engine=myisam
        
  Bug title slightly misleading. The problem was that syntax 
  errors (1064) were mistakenly generated for the following statements:
  CREATE TABLESPACE
  ALTER TABLESPACE
  DROP TABLESPACE
  CREATE LOGFILE GROUP
  ALTER LOGFILE GROUP
  DROP LOGFILE GROUP
  
  These statments used without any extra clauses gave syntax errors. 
  Adding one or more clauses would remove the syntax error, even if 
  those clauses are all defined as optional. The fix changes the 
  grammar to accept statements without extra clauses so that the 
  above statments give the proper error message used with engine=myisam:
  ERROR 1478 (HY000): Table storage engine 'MyISAM' does not support the 
  create option 'TABLESPACE or LOGFILE GROUP'
  
  Note that the ENGINE clause was optional before this fix even if this
  does not match the current version of the reference manual where it
  is marked as required. The manual should therefore be updated marking
  the ENGINE clause as optional for all statements listed above.
  
  Parser.test appended with a test of various statements that should
  give error 1478 ER_ILLEGAL_HA_CREATE_OPTION, but before gave syntax error.
------------------------------------------------------------
revno: 2771
committer: Dmitry Lenev 
branch nick: mysql-6.0-runtime
timestamp: Fri 2009-05-01 17:37:34 +0400
message:
  Follow-up for fix for bug "Bug#43138: DROP DATABASE failure
  does not clean up message list".
  
  Fixed drop.test failure under non-debug server by moving part
  of test dependent on debug-only feature to separate .test file,
  which won't be run for non-debug versions of server.
------------------------------------------------------------
revno: 2770
committer: Magne Mahre 
branch nick: mysql-6.0-runtime-fix42461
timestamp: Thu 2009-04-30 18:57:43 +0200
message:
  Bug #42461 Plugins: st_mysql_lex_string differs between plugin.h and m_string.h
        
  include/m_string.h and include/mysql/plugin.h had different definition
  of the type of the length attribute (size_t vs. unsigned int).
        
  Decided to use size_t as the common type, as this is the type used
  in the Single Unix Specification everywhere a string's length is
  given.
        
  No specific test case is added, as several existing test cases use
  MYSQL_LEX_STRING from plugins (in particular the maria suite).
------------------------------------------------------------
revno: 2769
committer: Magne Mahre 
branch nick: mysql-6.0-runtime-fix-backup-backup_log
timestamp: Thu 2009-04-30 18:53:50 +0200
message:
  Added a test to check if the file name length exceeds the OS/platform
  maximum file name length.
------------------------------------------------------------
revno: 2768
committer: Alexander Nozdrin 
branch nick: 6.0-rt-bug43138.3
timestamp: Thu 2009-04-30 19:31:30 +0400
message:
  Fix for Bug#43138: DROP DATABASE failure does not clean up message list.
  
  The problem was that the high-level function mysql_rm_db() invoked
  low-level mysql_rm_table_part2(), which reported low-level error
  (Unknown table) if SE refused to delete a table. Also when
  mysql_rm_table_part2() reported an error, it didn't add corresponding
  warning into the list (because it is used from other places where such
  behaviour is required).
  
  The fix is to
    1. Remove no_warnings_for_error usage from sql_table.cc
    2. Improve internal error handler support in THD, so that
       a stack of error handlers is allowed.
    3. Create an internal error handler (Drop_table_error_handler)
       to silence useless warnings.
    4. Use the handler in DROP DATABASE and DROP TABLE statements.
------------------------------------------------------------
revno: 2767
committer: Alexander Nozdrin 
branch nick: 6.0-rt
timestamp: Fri 2009-04-24 14:04:14 +0400
message:
  Pull from 6.0
------------------------------------------------------------
revno: 2766
committer: Alexander Nozdrin 
branch nick: 6.0-rt
timestamp: Wed 2009-04-22 13:22:10 +0400
message:
  Do not run the ndb, rpl_ndb test suites in regular builds
------------------------------------------------------------
revno: 2765
committer: Davi Arnaut 
branch nick: mysql-6.0-runtime
timestamp: Mon 2009-04-06 20:03:28 -0300
message:
  Post-merge fix: remove reference to removed file.
------------------------------------------------------------
revno: 2764
committer: Davi Arnaut 
branch nick: mysql-6.0-runtime
timestamp: Mon 2009-04-06 15:36:46 -0300
message:
  Remove unused and ancient files and facilities.
------------------------------------------------------------
revno: 2763
committer: Davi Arnaut 
branch nick: 41971-6.0
timestamp: Thu 2009-04-02 16:39:33 -0300
message:
  Bug#41971: Thread state on embedded server is always "Writing to net"
  
  The problem is that the state of a thread on a embedded server is
  always displayed as "Writing to net", which is wrong as there is
  no "network" in the embedded server.
  
  The solution is only exclude, on a embedded server, the thread
  state conditions that are related to network operations. Other
  thread states related to waiting on conditions or other operations
  are preserved.
------------------------------------------------------------
revno: 2762
committer: Alexander Nozdrin 
branch nick: 6.0-rt-bug37795.3
timestamp: Thu 2009-04-02 12:15:00 +0400
message:
  Patch for Bug#37795: main.innodb_mysql crashes randomly.
  
  It was a test case problem: one 'reap' statement was forgotten.
------------------------------------------------------------
revno: 2761
committer: Magne Mahre 
branch nick: mysql-6.0-runtime-fix33693
timestamp: Wed 2009-04-01 20:00:07 +0200
message:
  Bug #33693 general log name and location depend on PID file, 
             not on predefined values
              
  The default name of the PID file was constructed, as documented, 
  based on the hostname.  This name was subsequently used as the
  base for the general log file name.   If the name of the PID
  file was overridden in the configuration, and no explicit name
  was set for the general log file, the path location for the
  PID file was used also for the general log file.
              
  A new variable, 'default_logfile_name', has been introduced.  This name
  is constructed based on the hostname, and is then used to
  construct both the PID file and the general log file.
              
  The general log file will now, unless explicitly set, be
  located in the server data directory (as documentated in
  the server docs)
------------------------------------------------------------
revno: 2760
committer: Alexander Nozdrin 
branch nick: 6.0-rt-bug39542.2
timestamp: Wed 2009-04-01 12:16:35 +0400
message:
  Patch for Bug#39542: main.trigger_compat fails sporadically on windows.
  
  The patch actually enhances mysqltest directives -- 'move_file' has
  been introduced.
------------------------------------------------------------
revno: 2759
committer: Magne Mahre 
branch nick: mysql-6.0-runtime-fix38124
timestamp: Tue 2009-03-31 18:47:35 +0200
message:
  Bug #38124 "general_log_file" variable silently unset when using expression
              
  When assigning the new string value to the variable, the
  Item::str_value member was used.  This is not according to
  the protocol.  str_value is an internal member used for
  temporary assignments, and is not consistently set for all
  string operations.  It is set for constant strings, so it would
  work in these cases, but not for string functions (concat,
  substr, etc.)
              
  The correct approach is to use Item::val_str(..) to evaluate
  and retrieve the string.

Thread
Weekly Falcon bazaar mergeJohn H. Embretsen20 May