An error occurred fetching the project authors.
  1. 26 Aug, 2008 2 commits
  2. 19 Aug, 2008 1 commit
  3. 14 Jul, 2008 1 commit
    • Marc Alff's avatar
      Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on · 0816ee6d
      Marc Alff authored
      build)
      
      The crash was caused by freeing the internal parser stack during the parser
      execution.
      This occured only for complex stored procedures, after reallocating the parser
      stack using my_yyoverflow(), with the following C call stack:
      - MYSQLparse()
      - any rule calling sp_head::restore_lex()
      - lex_end()
      - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
      
      The root cause is the implementation of stored procedures, which breaks the
      assumption from 4.1 that there is only one LEX structure per parser call.
      
      The solution is to separate the LEX structure into:
      - attributes that represent a statement (the current LEX structure),
      - attributes that relate to the syntax parser itself (Yacc_state),
      so that parsing multiple statements in stored programs can create multiple
      LEX structures while not changing the unique Yacc_state.
      
      Now, Yacc_state and the existing Lex_input_stream are aggregated into
      Parser_state, a structure that represent the complete state of the (Lexical +
      Syntax) parser.
      0816ee6d
  4. 19 Jun, 2008 1 commit
    • Andrei Elkin's avatar
      Bug#36443 Server crashes when executing insert when insert trigger on table · b8d44950
      Andrei Elkin authored
                              
            The crash appeared to be a result of allocating an instance of Discrete_interval 
            automatically that that was referred in out-of-declaration scope.
                              
            Fixed with correcting backing up and restoring scheme of
            auto_inc_intervals_forced, introduced by bug#33029, by means of shallow copying;
            added simulation code that forces executing those fixes of the former bug that
            targeted at master-and-slave having incompatible bug#33029-prone versions.
      b8d44950
  5. 20 May, 2008 1 commit
  6. 13 May, 2008 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #32858: Erro: "Incorrect usage of UNION and INTO" does not take · f6951f3e
      gkodinov/kgeorge@magare.gmz authored
      subselects into account
        
      It is forbidden to use the SELECT INTO construction inside UNION statements
      unless on the last SELECT of the union. The parser records whether it 
      has seen INTO or not when parsing a UNION statement. But if the INTO was
      legally used in an outer query, an error is thrown if UNION is seen in a
      subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and 
      mitigate the error unless it collides with the UNION.
      f6951f3e
  7. 16 Apr, 2008 1 commit
    • kostja@bodhi.(none)'s avatar
      WL#4165 "Prepared statements: validation". · 7289eccf
      kostja@bodhi.(none) authored
      Add metadata validation to ~20 more SQL commands. Make sure that
      these commands actually work in ps-protocol, since until now they
      were enabled, but not carefully tested.
      Fixes the ml003 bug found by Matthias during internal testing of the
      patch.
      7289eccf
  8. 08 Apr, 2008 1 commit
    • kostja@dipika.(none)'s avatar
      Tentative implementation of · d1f93762
      kostja@dipika.(none) authored
      WL#4165 Prepared statements: validation 
      WL#4166 Prepared statements: automatic re-prepare
      Fixes
      Bug#27430 Crash in subquery code when in PS and table DDL changed after PREPARE
      Bug#27690 Re-execution of prepared statement after table was replaced with a view crashes
      Bug#27420 A combination of PS and view operations cause error + assertion on shutdown
      
      The basic idea of the patch is to keep track of table metadata between
      prepared statement prepare and execute. If some table used in the statement
      has changed, the prepared statement is re-prepared before execution.
      
      See WL#4165 and WL#4166 contents and comments in the code for details
      of the implementation.
      d1f93762
  9. 29 Mar, 2008 1 commit
    • aelkin/andrei@mysql1000.(none)'s avatar
      Bug #35675 reset master finds assert if a binlog file can not be deleted · ba7b1a7e
      aelkin/andrei@mysql1000.(none) authored
      If a binlog file is manually replaced with a namesake directory the internal purging did
      not handle the error of deleting the file so that eventually
      a post-execution guards fires an assert.
      
      Fixed with reusing a snippet of code for bug@18199 to tolerate lack of the file but no other error 
      at an attempt to delete it.
      The same applied to the index file deletion.
      
      The cset carries pieces of manual merging.
      ba7b1a7e
  10. 17 Mar, 2008 1 commit
  11. 14 Mar, 2008 2 commits
    • hezx@mail.hezx.com's avatar
      BUG#33029 5.0 to 5.1 replication fails on dup key when inserting · a3d02647
      hezx@mail.hezx.com authored
      using a trig in SP
      
      For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
      trigger caused an INSERT into an AUTO_INCREMENT column, the
      generated AUTO_INCREMENT value should not be written into the
      binary log, which means if a statement does not generate
      AUTO_INCREMENT value itself, there will be no Intvar event (SET
      INSERT_ID) associated with it even if one of the stored routine
      or trigger caused generation of such a value. And meanwhile, when
      executing a stored routine or trigger, it would ignore the
      INSERT_ID value even if there is a INSERT_ID value available set
      by a SET INSERT_ID statement.
      
      Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
      written into the binary log, and the value will be used if
      available when executing the stored routine or trigger.
      
      Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
      (referenced as the buggy versions in the text below), when a
      statement that generates AUTO_INCREMENT value by the top
      statement was executed in the body of a SP, all statements in the
      SP after this statement would be treated as if they had generated
      AUTO_INCREMENT by the top statement.  When a statement that did
      not generate AUTO_INCREMENT value by the top statement but by a
      function/trigger called by it, an erroneous Intvar event would be
      associated with the statement, this erroneous INSERT_ID value
      wouldn't cause problem when replicating between masters and
      slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
      value was not used when executing functions/triggers. But when
      replicating from buggy versions to 5.1.12 or newer, which will
      use the INSERT_ID value in functions/triggers, the erroneous
      value will be used, which would cause duplicate entry error and
      cause the slave to stop.
      
      The patch for 5.1 fixed it to ignore the SET INSERT_ID value when
      executing functions/triggers if it is replicating from a master
      of buggy versions, another patch for 5.0 fixed it not to generate
      the erroneous Intvar event.
      a3d02647
    • hezx@mail.hezx.com's avatar
      BUG#33029 5.0 to 5.1 replication fails on dup key when inserting · 97ae23f4
      hezx@mail.hezx.com authored
      using a trig in SP
      
      For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
      trigger caused an INSERT into an AUTO_INCREMENT column, the
      generated AUTO_INCREMENT value should not be written into the
      binary log, which means if a statement does not generate
      AUTO_INCREMENT value itself, there will be no Intvar event (SET
      INSERT_ID) associated with it even if one of the stored routine
      or trigger caused generation of such a value. And meanwhile, when
      executing a stored routine or trigger, it would ignore the
      INSERT_ID value even if there is a INSERT_ID value available set
      by a SET INSERT_ID statement.
      
      Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
      written into the binary log, and the value will be used if
      available when executing the stored routine or trigger.
      
      Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
      (referenced as the buggy versions in the text below), when a
      statement that generates AUTO_INCREMENT value by the top
      statement was executed in the body of a SP, all statements in the
      SP after this statement would be treated as if they had generated
      AUTO_INCREMENT by the top statement.  When a statement that did
      not generate AUTO_INCREMENT value by the top statement but by a
      function/trigger called by it, an erroneous Intvar event would be
      associated with the statement, this erroneous INSERT_ID value
      wouldn't cause problem when replicating between masters and
      slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
      value was not used when executing functions/triggers. But when
      replicating from buggy versions to 5.1.12 or newer, which will
      use the INSERT_ID value in functions/triggers, the erroneous
      value will be used, which would cause duplicate entry error and
      cause the slave to stop.
      
      The patch for 5.0 fixed it not to generate the erroneous Intvar
      event, another patch for 5.1 fixed it to ignore the SET INSERT_ID
      value when executing functions/triggers if it is replicating from
      a master of buggy versions.
      97ae23f4
  12. 05 Mar, 2008 1 commit
  13. 19 Feb, 2008 4 commits
    • tsmith@ramayana.hindu.god's avatar
      Applied InnoDB snapshot innodb-5.1-ss2298 · b8b6c7fc
      tsmith@ramayana.hindu.god authored
      Fixes the following bugs:
      
      - Bug #33349: possible race condition revolving around data dictionary and repartitioning
        Introduce retry/sleep logic as a workaround for a transient bug
        where ::open fails for partitioned tables randomly if we are using
        one file per table.
      
      - Bug #34053: normal users can enable innodb_monitor logging
        In CREATE TABLE and DROP TABLE check whether the table in question is one
        of the magic innodb_monitor tables and whether the user has enough rights
        to mess with it before doing anything else.
      
      - Bug #22868: 'Thread thrashing' with > 50 concurrent conns under an upd-intensive workloadw
      - Bug #29560: InnoDB >= 5.0.30 hangs on adaptive hash rw-lock 'waiting for an X-lock'
        This is a combination of changes that forward port the scalability fix applied to 5.0
        through r1001.
        It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
        scalability fix of 5.0)
        Then it applies r1001 to 5.0 which is the original scalability fix.
        Finally it applies r2082 which fixes an issue with the original fix.
      
      - Bug #30930: Add auxiliary function to retrieve THD::thread_id
        Add thd_get_thread_id() function.  Also make check_global_access() function
        visible to InnoDB under INNODB_COMPATIBILITY_HOOKS #define.
      b8b6c7fc
    • kostja@dipika.(none)'s avatar
    • kostja@dipika.(none)'s avatar
      Rename send_ok to my_ok. Similarly to my_error, it only records the status, · f106d973
      kostja@dipika.(none) authored
      does not send it to the client.
      f106d973
    • kostja@dipika.(none)'s avatar
      A fix and a test case for Bug#12713 "Error in a stored function called from · acf9b1f3
      kostja@dipika.(none) authored
      a SELECT doesn't cause ROLLBACK of statem".
      
      The idea of the fix is to ensure that we always commit the current
      statement at the end of dispatch_command(). In order to not issue
      redundant disc syncs, an optimization of the two-phase commit
      protocol is implemented to bypass the two phase commit if
      the transaction is read-only.
      acf9b1f3
  14. 12 Feb, 2008 2 commits
  15. 09 Feb, 2008 1 commit
  16. 13 Dec, 2007 2 commits
  17. 12 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Bug#12713 "Error in a stored function called from a SELECT doesn't · ebb9c5d9
      kostja@bodhi.(none) authored
      cause ROLLBACK of statement", part 1. Review fixes.
      
      Do not send OK/EOF packets to the client until we reached the end of 
      the current statement.
      This is a consolidation, to keep the functionality that is shared by all 
      SQL statements in one place in the server.
      Currently this functionality includes:
      - close_thread_tables()
      - log_slow_statement().
      
      After this patch and the subsequent patch for Bug#12713, it shall also include:
      - ha_autocommit_or_rollback()
      - net_end_statement()
      - query_cache_end_of_result().
      
      In future it may also include:
      - mysql_reset_thd_for_next_command().
      ebb9c5d9
  18. 20 Nov, 2007 2 commits
    • davi@endora.local's avatar
      Bug#31397 Inconsistent drop table behavior of handler tables. · 94e6e4ff
      davi@endora.local authored
      The problem is that DROP TABLE and other DDL statements failed to
      automatically close handlers associated with tables that were marked
      for reopen (FLUSH TABLES).
      
      The current implementation fails to properly discard handlers of
      dropped tables (that were marked for reopen) because it searches
      on the open handler tables list and using the current alias of the
      table being dropped. The problem is that it must not use the open
      handler tables list to search because the table might have been
      closed (marked for reopen) by a flush tables command and also it
      must not use the current table alias at all since multiple different
      aliases may be associated with a single table. This is specially
      visible when a user has two open handlers (using alias) of a same
      table and a flush tables command is issued before the table is
      dropped (see test case). Scanning the handler table list is also
      useless for dropping handlers associated with temporary tables,
      because temporary tables are not kept in the THD::handler_tables
      list.
      
      The solution is to simple scan the handlers hash table searching
      for, and deleting all handlers with matching table names if the
      reopen flag is not passed to the flush function, indicating that
      the handlers should be deleted. All matching handlers are deleted
      even if the associated the table is not open.
      94e6e4ff
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #32533. · 351d9f66
      gshchepa/uchum@gleb.loc authored
      8bit escape characters, termination and enclosed characters
      were silently ignored by SELECT INTO query, but LOAD DATA INFILE
      algorithm is 8bit-clean, so data was corrupted during 
      encoding.
      351d9f66
  19. 15 Nov, 2007 1 commit
    • anozdrin/alik@station.'s avatar
      A patch for BUG#19723: kill of active connection yields · e8343ca8
      anozdrin/alik@station. authored
      different error code depending on platform.
      
      On Mac OS X, KILL statement issued to kill the current
      connection would return a different error code and message than on
      other platforms ('MySQL server has gone away' instead of 'Shutdown
      in progress').
      
      The reason for this difference was that on Mac OS X we have macro
      SIGNAL_WITH_VIO_CLOSE defined. This macro forces KILL
      implementation to close the communication socket of the thread
      that is being killed. SIGNAL_WITH_VIO_CLOSE macro is defined on
      platforms where just sending a signal is not a reliable mechanism
      to interrupt the thread from sleeping on a blocking system call.
      In a nutshell, closing the socket is a hack to work around an
      operating system bug and awake the blocked thread no matter what.
      
      However, if the thread that is being killed is the same
      thread that issued KILL statement, closing the socket leads to a
      prematurely lost connection. At the same time it is not necessary
      to close the socket in this case, since the thread in question
      is not inside a blocking system call.
      
      The fix, therefore, is to not close the socket if the thread that
      is being killed is the same that issued KILL statement, even with
      defined SIGNAL_WITH_VIO_CLOSE.
      e8343ca8
  20. 10 Nov, 2007 1 commit
  21. 31 Oct, 2007 1 commit
  22. 30 Oct, 2007 2 commits
  23. 23 Oct, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #31663: if the FIELDS TERMINATED BY string · 5adc332c
      gshchepa/uchum@gleb.loc authored
      in the SELECT INTO OUTFILE clause starts with a special
      character (one of n, t, r, b, 0, Z or N) and ENCLOSED BY
      is empty, every occurrence of this character within a
      field value is duplicated.
      
      Duplication has been avoided.
      New warning message has been added: "First character of
      the FIELDS TERMINATED string is ambiguous; please use
      non-optional and non-empty FIELDS ENCLOSED BY".
      5adc332c
  24. 19 Oct, 2007 2 commits
    • kostja@bodhi.(none)'s avatar
      Rename: query_error -> is_slave_error. · 7c00f8a3
      kostja@bodhi.(none) authored
      Add comments.
      7c00f8a3
    • anozdrin/alik@station.'s avatar
      Patch for BUG#31111: --read-only crashes MySQL (events fail to load). · c60397ef
      anozdrin/alik@station. authored
      There actually were several problems here:
        - WRITE-lock is required to load events from the mysql.event table,
          but in the read-only mode an ordinary user can not acquire it;
        - Security_context::master_access attribute was not properly
          initialized in Security_context::init(), which led to differences
          in behavior with and without debug configure options.
        - if the server failed to load events from mysql.event, it forgot to
          close the mysql.event table, that led to the coredump, described
          in the bug report.
      
      The patch is to fix all these problems:
        - Use the super-user to acquire WRITE-lock on the mysql.even table;
        - The WRITE-lock is acquired by the event scheduler in two cases:
          - on initial loading of events from the database;
          - when an event has been executed, so its attributes should
            be updated.
          Other cases when WRITE-lock is needed for the mysql.event table
          happen under the user account. So, nothing should be changed there
          for the read-only mode. The user is able to create/update/drop
          an event only if he is a super-user.
        - Initialize Security_context::master_access;
        - Close the mysql.event table in case something went wrong.
      c60397ef
  25. 16 Oct, 2007 1 commit
  26. 15 Oct, 2007 1 commit
  27. 11 Oct, 2007 2 commits
    • monty@mysql.com/narttu.mysql.fi's avatar
      Moved a lot of old bug fixes and safe cleanups from Maria 5.1 tree to 5.1 · 7887babe
      monty@mysql.com/narttu.mysql.fi authored
      - Reserver namespace and place in frm for TABLE_CHECKSUM and PAGE_CHECKSUM create options
      - Added syncing of directory when creating .frm files
      - Portability fixes
      - Added missing cast that could cause bugs
      - Code cleanups
      - Made some bit functions inline
      - Moved things out of myisam.h to my_handler.h to make them more accessable
      - Renamed some myisam variables and defines to make them more globaly usable (as they are used outside of MyISAM)
      - Fixed bugs in error conditions
      - Use compiler time asserts instead of run time
      - Fixed indentation
      HA_EXTRA_PREPARE_FOR_DELETE -> HA_EXTRA_PREPARE_FOR_DROP as the old name was wrong
      (Added a define for old value to ensure we don't break any old code)
      Added HA_EXTRA_PREPARE_FOR_RENAME as a signal for rename (before we used a DROP signal which is wrong)
      - Initialize error messages early to get better errors when mysqld or an engine fails to start
      - Fix windows bug that query_performance_frequency was not initialized if registry code failed
      - thread_stack -> my_thread_stack_size
      7887babe
    • anozdrin/alik@station.'s avatar
      A patch for BUG#31418: User locks misfunctioning after · 7237c316
      anozdrin/alik@station. authored
      mysql_change_user().
      
      The problem was that THD::ull was not reset in THD::cleanup().
      
      The fix is to reset it.
      7237c316
  28. 10 Oct, 2007 2 commits