1. 26 Jul, 2006 3 commits
    • unknown's avatar
      Applied innodb-5.0-ss660 snapshot. · 1c65e1f7
      unknown authored
      
      innobase/btr/btr0cur.c:
        Applied innodb-5.0-ss660 snapshot.
         btr_cur_search_to_nth_level(): Reacquire btr_search_latch after
         inserting to the insert buffer. This was noticed while analyzing
         Bug#19081 but this shold not fix this bug since according to
         Heikki, btr_search_latch is not reserved during an insert.
      innobase/ibuf/ibuf0ibuf.c:
        Applied innodb-5.0-ss660 snapshot.
         ibuf_fixed_addr_page(): Add parameter space. As the insert buffer
         B-tree is only located in the system tablespace (space 0),
         IBUF_TREE_ROOT_PAGE_NO is only special in space 0.
      innobase/include/sync0rw.ic:
        Applied innodb-5.0-ss660 snapshot.
         rw_lock_s_unlock_func(): Change a debug assertion to a
         production assertion in order to track down Bug#19081.
      1c65e1f7
    • unknown's avatar
      Merge mysql.com:/home/alexi/innodb/mysql-4.1-work · f6bb4650
      unknown authored
      into  mysql.com:/home/alexi/innodb/mysql-5.0-work
        Null merge.
      
      
      innobase/ibuf/ibuf0ibuf.c:
        Null merge.
      f6bb4650
    • unknown's avatar
      Applied innodb-4.1-ss32 snapshot. · 5cb7afaf
      unknown authored
      
      innobase/ibuf/ibuf0ibuf.c:
        Applied innodb-4.1-ss32 snapshot.
         ibuf_fixed_addr_page(): Add parameter space. As the insert
         buffer B-tree is only located in the system tablespace
         (space 0), IBUF_TREE_ROOT_PAGE_NO is only special in space 0.
      5cb7afaf
  2. 11 Jul, 2006 1 commit
    • unknown's avatar
      Merge dl145k.mysql.com:/data0/mkindahl/bkroot/mysql-5.0-rpl · 94342039
      unknown authored
      into  dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.0-merge
      
      
      ndb/include/kernel/GlobalSignalNumbers.h:
        Auto merged
      ndb/src/kernel/blocks/dbdict/Dbdict.cpp:
        Auto merged
      ndb/src/kernel/blocks/dbdict/Dbdict.hpp:
        Auto merged
      ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
        Auto merged
      ndb/src/ndbapi/ndberror.c:
        Auto merged
      94342039
  3. 10 Jul, 2006 4 commits
  4. 09 Jul, 2006 1 commit
    • unknown's avatar
      BUG#20919 temp tables closing fails when binlog is off · 259ab342
      unknown authored
      closing temp tables through end_thread
      had a flaw in binlog-off branch of close_temporary_tables where
      next table to close was reset via table->next
       for (table= thd->temporary_tables; table; table= table->next)
      which was wrong since the current table instance got destoyed at
      	close_temporary(table, 1);
      
      The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.
      
      
      
      sql/sql_base.cc:
        no-binlog branch is fixed: scanning across temporary_tables must be careful to save next table since the current is being destroyed inside of close_temporary. 
        binlog-is-open case is ok.
      259ab342
  5. 06 Jul, 2006 3 commits
    • unknown's avatar
      Merge gbichot@bk-internal.mysql.com:/home/bk/mysql-5.0-rpl · fb51707b
      unknown authored
      into  gbichot3.local:/home/mysql_src/mysql-5.0
      
      fb51707b
    • unknown's avatar
      Merge gbichot3.local:/home/mysql_src/mysql-5.0-20524 · 4e8ca253
      unknown authored
      into  gbichot3.local:/home/mysql_src/mysql-5.0
      
      
      sql/handler.cc:
        Auto merged
      sql/handler.h:
        Auto merged
      sql/sql_insert.cc:
        Auto merged
      4e8ca253
    • unknown's avatar
      Fix for BUG#20524 "auto_increment_* not observed when inserting · 1ac39cfe
      unknown authored
      a too large value": the bug was that if MySQL generated a value for an
      auto_increment column, based on auto_increment_* variables, and this value
      was bigger than the column's max possible value, then that max possible
      value was inserted (after issuing a warning). But this didn't honour
      auto_increment_* variables (and so could cause conflicts in a master-master
      replication where one master is supposed to generated only even numbers,
      and the other only odd numbers), so now we "round down" this max possible
      value to honour auto_increment_* variables, before inserting it.
      
      
      mysql-test/r/rpl_auto_increment.result:
        result update. Before the fix, the result was that master inserted 127 in t1
        (which didn't honour auto_increment_* variables!),
        instead of failing with "duplicate key 125" like now.
      mysql-test/t/rpl_auto_increment.test:
        Test for BUG#20524 "auto_increment_* not observed when inserting
        a too large value".
        We also check the pathological case (table t2) where it's impossible to
        "round down".
        The fixer of BUG#20573 will be able to use table t2 for testing his fix.
      sql/handler.cc:
        If handler::update_auto_increment() generates a value larger than the field's
        max possible value, we used to simply insert this max possible value
        (after pushing a warning). Now we "round down" this max possible value to
        honour auto_increment_* variables (if at all possible), before trying the
        insertion.
      1ac39cfe
  6. 05 Jul, 2006 1 commit
    • unknown's avatar
      Fix for BUG#20188 "REPLACE or ON DUPLICATE KEY UPDATE in · 6943364c
      unknown authored
      auto_increment breaks binlog":
      if slave's table had a higher auto_increment counter than master's (even
      though all rows of the two tables were identical), then in some cases,
      REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate
      statement-based (it inserted different values on slave from on master).
      write_record() contained a "thd->next_insert_id=0" to force an adjustment
      of thd->next_insert_id after the update or replacement. But it is this
      assigment introduced indeterminism of the statement on the slave, thus
      the bug. For ON DUPLICATE, we replace that assignment by a call to
      handler::adjust_next_insert_id_after_explicit_value() which is deterministic
      (does not depend on slave table's autoinc counter). For REPLACE, this
      assignment can simply be removed (as REPLACE can't insert a number larger
      than thd->next_insert_id).
      We also move a too early restore_auto_increment() down to when we really know
      that we can restore the value.
      
      
      mysql-test/r/rpl_insert_id.result:
        result update, without the bugfix, slave's "3 350" were "4 350".
      mysql-test/t/rpl_insert_id.test:
        test for BUG#20188 "REPLACE or ON DUPLICATE KEY UPDATE in
        auto_increment breaks binlog".
        There is, in this order:
        - a test of the bug for the case of REPLACE
        - a test of basic ON DUPLICATE KEY UPDATE functionality which was not
        tested before
        - a test of the bug for the case of ON DUPLICATE KEY UPDATE
      sql/handler.cc:
        the adjustment of next_insert_id if inserting a big explicit value, is
        moved to a separate method to be used elsewhere.
      sql/handler.h:
        see handler.cc
      sql/sql_insert.cc:
        restore_auto_increment() means "I know I won't use this autogenerated
        autoincrement value, you are free to reuse it for next row". But we were
        calling restore_auto_increment() in the case of REPLACE: if write_row() fails
        inserting the row, we don't know that we won't use the value, as we are going to
        try again by doing internally an UPDATE of the existing row, or a DELETE
        of the existing row and then an INSERT. So I move restore_auto_increment()
        further down, when we know for sure we failed all possibilities for the row.
        Additionally, in case of REPLACE, we don't need to reset THD::next_insert_id:
        the value of thd->next_insert_id will be suitable for the next row.
        In case of ON DUPLICATE KEY UPDATE, resetting thd->next_insert_id is also
        wrong (breaks statement-based binlog), but cannot simply be removed, as
        thd->next_insert_id must be adjusted if the explicit value exceeds it.
        We now do the adjustment by calling
        handler::adjust_next_insert_id_after_explicit_value() (which, contrary to
        thd->next_insert_id=0, does not depend on the slave table's autoinc counter,
        and so is deterministic).
      6943364c
  7. 03 Jul, 2006 4 commits
  8. 29 Jun, 2006 4 commits
  9. 28 Jun, 2006 8 commits
    • unknown's avatar
      Merge mysql.com:/users/lthalmann/bkroot/mysql-5.0-rpl · c9dd8a9a
      unknown authored
      into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
      
      
      sql/ha_ndbcluster.cc:
        Auto merged
      c9dd8a9a
    • unknown's avatar
      BUG#20739. · dee92b5f
      unknown authored
      In the Windows build files, the "Max nt" configuration for some reason
      had the mysql_client_test project disabled. Enable it.
      
      
      VC++Files/mysql.sln:
        The "Max nt" configuration for some reason had the mysql_client_test
        project disabled. Enable it.
      dee92b5f
    • unknown's avatar
      Disabled test case for Windows (BUG#20753) · d78c0d80
      unknown authored
      d78c0d80
    • unknown's avatar
      BUG#20739 · 2ba7c59c
      unknown authored
      Improved definition of mysys configuration for -nt builds.
      
      
      VC++Files/mysql.sln:
        Use the name 'nt' instead of 'Release' for configuration.
      VC++Files/mysys/mysys.vcproj:
        Use the name 'nt' instead of 'Release' for configuration.
        Use separate output files for NT and non-NT configurations.
      2ba7c59c
    • unknown's avatar
      BUG#20739: __NT__ not probably defined for mysys project. · fced43c3
      unknown authored
      Make sure for the mysys project that __NT__ is defined in *nt solution
      configurations (but not in other configurations).
      
      
      VC++Files/mysql.sln:
        Define __NT__ in mysys for *nt configurations.
      VC++Files/mysys/mysys.vcproj:
        Add configurations with __NT__ defined.
      mysql-test/mysql-test-run.pl:
        Also allow testing a "Max nt" build.
      fced43c3
    • unknown's avatar
      Adding __NT__ to Max Win32 configuration. · 4202ec1c
      unknown authored
      4202ec1c
    • unknown's avatar
      Merge aivanov@bk-internal.mysql.com:/home/bk/mysql-5.0-rpl · c12cc071
      unknown authored
      into  mysql.com:/home/alexi/bugs/mysql-5.0-19208
      
      c12cc071
    • unknown's avatar
      Fixing BUG#17719 "Delete of binlog files fails on Windows" · 3524e191
      unknown authored
       and BUG#19208 "Test 'rpl000017' hangs on Windows".
       Both bugs are caused by attempting to delete an opened
       file and to create immediatedly a new one with the same
       name. On Windows it can be supported only on NT-platforms
       (by using FILE_SHARE_DELETE mode and with renaming the
       file before deletion). Because deleting not-closed files
       is not supported on all platforms (e.g. Win 98|ME) this
       is to be considered harmful and should be eliminated by
       a "code redesign".
      
      
      VC++Files/mysys/mysys.vcproj:
        To be sure that __NT__ is defined for Win configurations.
         Temporary, to be changed in more appropriate way.
      include/my_sys.h:
        Adding my_delete_allow_opened to be invoked to delete
         a (possibly) not closed file on Windows NT-platforms.
      mysys/my_delete.c:
        Adding nt_share_delete() function implementing
         a (possibly) not closed file deletion on Windows NT.
      sql/log.cc:
        MYSQL_LOG::reset_logs(): Deleting usually not
         closed binlog files.
      3524e191
  10. 27 Jun, 2006 2 commits
    • unknown's avatar
      Bug #19852 Restoring backup made from cluster with full data memory fails · 40f9f83d
      unknown authored
      - correction of previous patch
      
      40f9f83d
    • unknown's avatar
      Bug #19852 Restoring backup made from cluster with full data memory fails · 6f0bbc51
      unknown authored
      - make sure to allocate just enough pages in the fragments by using the actual
        row count from the backup, to avoid over allocation of pages to fragments, and
        thus avoid the bug
      
      
      ndb/include/kernel/GlobalSignalNumbers.h:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - distribute fragment complete to all participants to update row count
      ndb/include/kernel/signaldata/BackupContinueB.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - time slica writing of fragment info to ctl file
      ndb/include/kernel/signaldata/BackupImpl.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - 32 -> 64 bit on bytes and records
        - new signal fragment complete to all participants
      ndb/include/kernel/signaldata/BackupSignalData.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - 32 -> 64 bit on bytes and records
      ndb/include/kernel/signaldata/DictTabInfo.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - add min and max rows to dict tab info
      ndb/include/kernel/signaldata/LqhFrag.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added min and max rows to add frag req
      ndb/include/kernel/signaldata/TupFrag.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added min and max rows to add frag req
      ndb/include/ndbapi/NdbDictionary.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added get/set of min max rows
      ndb/src/common/debugger/signaldata/BackupImpl.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - 32 -> 64 bit on bytes and records
      ndb/src/common/debugger/signaldata/BackupSignalData.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - 32 -> 64 bit on bytes and records
      ndb/src/common/debugger/signaldata/DictTabInfo.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added min and max rows to dict tab info
      ndb/src/common/debugger/signaldata/LqhFrag.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added min and max rows to frag req
      ndb/src/kernel/blocks/backup/Backup.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - new section in backup with per fragment info in ctl file
        - 32 -> 64 bit on bytes and records
      ndb/src/kernel/blocks/backup/Backup.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - new section in backup with per fragment info in ctl file
        - 32 -> 64 bit on bytes and records
      ndb/src/kernel/blocks/backup/BackupFormat.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - new section in backup with per fragment info in ctl file
        - 32 -> 64 bit on bytes and records
      ndb/src/kernel/blocks/backup/BackupInit.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - new signal fragment complete to all participants
      ndb/src/kernel/blocks/dbdict/Dbdict.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added max and min rows to dict table object
      ndb/src/kernel/blocks/dbdict/Dbdict.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added max and min rows to dict table object
      ndb/src/kernel/blocks/dblqh/Dblqh.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added min and max rows to frag req
      ndb/src/kernel/blocks/dblqh/DblqhMain.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added min and max rows to frag req
      ndb/src/kernel/blocks/dbtup/Dbtup.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added min and max rows to frag req
      ndb/src/kernel/blocks/dbtup/DbtupMeta.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - added min and max rows to frag req
        - move memory allocation to fragment to after adding of attributes to get correct headsize
        - allocate pages to fragments according to min rows setting
      ndb/src/kernel/blocks/dbtup/DbtupPageMap.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - grow page allocation starting from 2 irrespective of first page allocation
      ndb/src/mgmsrv/MgmtSrvr.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - 32 -> 64 bits on bytes and records
      ndb/src/mgmsrv/MgmtSrvr.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - 32 -> 64 bits on bytes and records
      ndb/src/ndbapi/NdbDictionary.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - min and max rows in dict
      ndb/src/ndbapi/NdbDictionaryImpl.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - min and max rows in dict
      ndb/src/ndbapi/NdbDictionaryImpl.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - min and max rows in dict
      ndb/tools/restore/Restore.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - add retrieval of fragment info
      ndb/tools/restore/Restore.hpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - add retrieval of fragment info
      ndb/tools/restore/consumer_restore.cpp:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - set min in restore to the actual row count (this is the actual bug fix)
      sql/ha_ndbcluster.cc:
        Bug #19852  	Restoring backup made from cluster with full data memory fails
        - set min and max rows according to sql definition
      6f0bbc51
  11. 26 Jun, 2006 1 commit
  12. 24 Jun, 2006 1 commit
    • unknown's avatar
      Fix race condition in test case wait_timeout. · d0d405ee
      unknown authored
      Sometimes the helper connection (that is watching for the main connection
      to time out) would itself time out first, causing the test to fail.
      
      
      mysql-test/t/wait_timeout.test:
        Increase connection timeout in connection wait_con so we will not loose
        the connection that is watching for the real wait_timeout to trigger.
      d0d405ee
  13. 21 Jun, 2006 7 commits