An error occurred fetching the project authors.
  1. 28 May, 2007 1 commit
  2. 23 May, 2007 2 commits
    • dlenev@mockturtle.local's avatar
      5.1 version of fix for: · 8e8f4c05
      dlenev@mockturtle.local authored
        Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
                    by other connections"
        Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
      As well as:
        Bug #25578 "CREATE TABLE LIKE does not require any privileges
                    on source table".
      
      The first and the second bugs resulted in various errors and wrong
      binary log order when one tried to execute concurrently CREATE TABLE LIKE
      statement and DDL statements on source table or DML/DDL statements on its
      target table.
      
      The problem was caused by incomplete protection/table-locking against
      concurrent statements implemented in mysql_create_like_table() routine.
      We solve it by simply implementing such protection in proper way.
      Most of actual work for 5.1 was already done by fix for bug 20662 and
      preliminary patch changing locking in ALTER TABLE.
      
      The third bug allowed user who didn't have any privileges on table create
      its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
      
      This patch solves this problem by adding privilege check, which was missing.
      
      Finally it also removes some duplicated code from mysql_create_like_table()
      and thus fixes bug #26869 "TABLE_LIST::table_name_length inconsistent with
      TABLE_LIST::table_name".
      8e8f4c05
    • dlenev@mockturtle.local's avatar
      5.0 version of fix for: · c07b3670
      dlenev@mockturtle.local authored
       Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
                   by other connections"
       Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
      As well as:
       Bug #25578 "CREATE TABLE LIKE does not require any privileges
                   on source table".
      
      The first and the second bugs resulted in various errors and wrong
      binary log order when one tried to execute concurrently CREATE TABLE LIKE
      statement and DDL statements on source table or DML/DDL statements on its
      target table.
      
      The problem was caused by incomplete protection/table-locking against
      concurrent statements implemented in mysql_create_like_table() routine.
      We solve it by simply implementing such protection in proper way (see
      comment for sql_table.cc for details).
      
      The third bug allowed user who didn't have any privileges on table create
      its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
      
      This patch solves this problem by adding privilege check, which was missing.
      
      Finally it also removes some duplicated code from mysql_create_like_table().
      
      Note that, altough tests covering concurrency-related aspects of CREATE TABLE
      LIKE behaviour will only be introduced in 5.1, they were run manually for
      this patch as well.
      c07b3670
  3. 19 May, 2007 1 commit
    • dlenev@mockturtle.local's avatar
      Patch changing how ALTER TABLE implementation handles table locking · b0dfdc2b
      dlenev@mockturtle.local authored
      and invalidation in the most general case (non-temporary table and
      not simple RENAME or ENABLE/DISABLE KEYS or partitioning command).
      
      See comment for sql/sql_table.cc for more information.
      
      These changes are prerequisite for 5.1 version of fix for bug #23667
      "CREATE TABLE LIKE is not isolated from alteration by other connections"
      b0dfdc2b
  4. 11 May, 2007 2 commits
    • dlenev@mockturtle.local's avatar
      Fix for: · 4cafc8ee
      dlenev@mockturtle.local authored
        Bug #20662 "Infinite loop in CREATE TABLE IF NOT EXISTS ... SELECT
                    with locked tables"
        Bug #20903 "Crash when using CREATE TABLE .. SELECT and triggers"
        Bug #24738 "CREATE TABLE ... SELECT is not isolated properly"
        Bug #24508 "Inconsistent results of CREATE TABLE ... SELECT when
                    temporary table exists"
      
      Deadlock occured when one tried to execute CREATE TABLE IF NOT
      EXISTS ... SELECT statement under LOCK TABLES which held
      read lock on target table.
      Attempt to execute the same statement for already existing
      target table with triggers caused server crashes.
      Also concurrent execution of CREATE TABLE ... SELECT statement
      and other statements involving target table suffered from
      various races (some of which might've led to deadlocks).
      Finally, attempt to execute CREATE TABLE ... SELECT in case
      when a temporary table with same name was already present
      led to the insertion of data into this temporary table and
      creation of empty non-temporary table.
       
      All above problems stemmed from the old implementation of CREATE
      TABLE ... SELECT in which we created, opened and locked target
      table without any special protection in a separate step and not
      with the rest of tables used by this statement.
      This underminded deadlock-avoidance approach used in server
      and created window for races. It also excluded target table
      from prelocking causing problems with trigger execution.
      
      The patch solves these problems by implementing new approach to
      handling of CREATE TABLE ... SELECT for base tables.
      We try to open and lock table to be created at the same time as
      the rest of tables used by this statement. If such table does not
      exist at this moment we create and place in the table cache special
      placeholder for it which prevents its creation or any other usage
      by other threads.
      We still use old approach for creation of temporary tables.
      
      Note that we have separate fix for 5.0 since there we use slightly
      different less intrusive approach.
      4cafc8ee
    • dlenev@mockturtle.local's avatar
      Fix for: · 8b93e52e
      dlenev@mockturtle.local authored
        Bug #20662 "Infinite loop in CREATE TABLE IF NOT EXISTS ... SELECT
                    with locked tables"
        Bug #20903 "Crash when using CREATE TABLE .. SELECT and triggers"
        Bug #24738 "CREATE TABLE ... SELECT is not isolated properly"
        Bug #24508 "Inconsistent results of CREATE TABLE ... SELECT when
                    temporary table exists"
       
      Deadlock occured when one tried to execute CREATE TABLE IF NOT
      EXISTS ... SELECT statement under LOCK TABLES which held
      read lock on target table.
      Attempt to execute the same statement for already existing
      target table with triggers caused server crashes.
      Also concurrent execution of CREATE TABLE ... SELECT statement
      and other statements involving target table suffered from
      various races (some of which might've led to deadlocks).
      Finally, attempt to execute CREATE TABLE ... SELECT in case
      when a temporary table with same name was already present
      led to the insertion of data into this temporary table and
      creation of empty non-temporary table.
       
      All above problems stemmed from the old implementation of CREATE
      TABLE ... SELECT in which we created, opened and locked target
      table without any special protection in a separate step and not
      with the rest of tables used by this statement.
      This underminded deadlock-avoidance approach used in server
      and created window for races. It also excluded target table
      from prelocking causing problems with trigger execution.
        
      The patch solves these problems by implementing new approach to
      handling of CREATE TABLE ... SELECT for base tables.
      We try to open and lock table to be created at the same time as
      the rest of tables used by this statement. If such table does not
      exist at this moment we create and place in the table cache special
      placeholder for it which prevents its creation or any other usage
      by other threads.
      
      We still use old approach for creation of temporary tables.
      
      Also note that we decided to postpone introduction of some tests
      for concurrent behaviour of CREATE TABLE ... SELECT till 5.1.
      The main reason for this is absence in 5.0 ability to set @@debug
      variable at runtime, which can be circumvented only by using several
      test files with individual .opt files. Since the latter is likely
      to slowdown test-suite unnecessary we chose not to push this tests
      into 5.0, but run them manually for this version and later push
      their optimized version into 5.1
      8b93e52e
  5. 08 May, 2007 2 commits
    • thek@adventure.(none)'s avatar
      5e774747
    • thek@adventure.(none)'s avatar
      Bug #27792 query cache returns wrong result, with certain system variables · 4ea05eae
      thek@adventure.(none) authored
       - Queries in the query cache are identified by the individual 
         characters in the query statement, the current database and 
         the current environment expressed as a set of system variable
         flags.
       - Since the set of environment flags didn't properly describe the
         current environment unexpected results were returned from the 
         query cache.
       - Query cache is now cleared when the variable ft_boolean_syntax is 
         updated.
       - An identification flag for the variable default_week_format is 
         added to the query cache record.
       
      Thanks to Martin Friebe who has supplied significant parts of this patch.
      4ea05eae
  6. 04 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27759: Wrong DATE/DATETIME comparison in LEAST()/GREATEST() functions. · 239f727b
      evgen@moonbone.local authored
      The LEAST/GREATEST functions compared DATE/DATETIME values as
      strings which in some cases could lead to a wrong result.
      
      A new member function called cmp_datetimes() is added to the
      Item_func_min_max class. It compares arguments in DATETIME context
      and returns index of the least/greatest argument.
      The Item_func_min_max::fix_length_and_dec() function now detects when
      arguments should be compared in DATETIME context and sets the newly
      added flag compare_as_dates. It indicates that the cmp_datetimes() function
      should be called to get a correct result.
      Item_func_min_max::val_xxx() methods are corrected to call the
      cmp_datetimes() function when needed.
      Objects of the Item_splocal class now stores and reports correct original
      field type.
      239f727b
  7. 30 Apr, 2007 1 commit
  8. 28 Apr, 2007 1 commit
    • kaa@polly.local's avatar
      Fix for bug #24912 "problems with bigint in abs() ceiling() round() truncate()... · 050c6723
      kaa@polly.local authored
      Fix for bug #24912 "problems with bigint in abs() ceiling() round() truncate() mod()" and a number of related problems:
      
      - unsigned flag was not handled correctly for a number of mathematical funcions, which led to incorrect results
      - passing large values as the number of decimals to ROUND() resulted in incorrect results and even server crashes in some cases
      - reverted the fix and the testcase for bug #10083 as it violates the manual
      - fixed some testcases which relied on broken ROUND() behavior
      050c6723
  9. 26 Apr, 2007 1 commit
  10. 24 Apr, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#25411 (trigger code truncated), PART I · fc809c70
      malff/marcsql@weblab.(none) authored
      The issue found with bug 25411 is due to the function skip_rear_comments()
      which damages the source code while implementing a work around.
      The root cause of the problem is in the lexical analyser, which does not
      process special comments properly.
      For special comments like :
      [1] aaa /*!50000 bbb */ ccc
      since 5.0 is a version older that the current code, the parser is in lining
      the content of the special comment, so that the query to process is
      [2] aaa bbb ccc
      However, the text of the query captured when processing a stored procedure,
      stored function or trigger (or event in 5.1), can be after rebuilding it:
      [3] aaa bbb */ ccc
      which is wrong.
      
      To fix bug 25411 properly, the lexical analyser needs to return [2] when
      in lining special comments.
      In order to implement this, some preliminary cleanup is required in the code,
      which is implemented by this patch.
      
      Before this change, the structure named LEX (or st_lex) contains attributes
      that belong to lexical analysis, as well as attributes that represents the
      abstract syntax tree (AST) of a statement.
      Creating a new LEX structure for each statements (which makes sense for the
      AST part) also re-initialized the lexical analysis phase each time, which
      is conceptually wrong.
      
      With this patch, the previous st_lex structure has been split in two:
      - st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
      has not been changed to avoid a bigger impact in the code base.
      - class lex_input_stream represents the internal state of the lexical
        analyser, which by definition should *not* be reinitialized when parsing
        multiple statements from the same input stream.
      
      This change is a pre-requisite for bug 25411, since the implementation of
      lex_input_stream will later improve to deal properly with special comments,
      and this processing can not be done with the current implementation of
      sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
      
      This change set alone does not fix bug 25411.
      fc809c70
  11. 18 Apr, 2007 1 commit
    • msvensson@pilot.blaudden's avatar
      Bug#25452 mysql_upgrade access denied · 20e622dc
      msvensson@pilot.blaudden authored
       - Improve mysql_upgrade and add comments describing it's logic
       - Don't look for mysql and mysqlcheck randomly, use dir where mysql_upgrade
        was started from
       - Don't look for mysql_fix_privilege_tables.sql randomly, compile
        in the mysql_fix_privilege_tables.sql file and use that to upgrade
        the system tables of MySQL
       - Check for any unexpected error returned from runnning the mysql_fix_privilege_tables SQL
       - Fix bug#26639, bug#24248 and bug#25405
      20e622dc
  12. 09 Apr, 2007 1 commit
    • bar@mysql.com's avatar
      Bug#22648 LC_TIME_NAMES: Setting GLOBAL has no effect · 4341df8c
      bar@mysql.com authored
      Problem: setting/displaying @@LC_TIME_NAMES didn't distinguish between
      GLOBAL and SESSION variable types - always SESSION variable
      was set/shonw.
      Fix: set either global or session value.
      Also, "mysqld --lc-time-names" was added to set "global default" value.
      4341df8c
  13. 04 Apr, 2007 3 commits
    • mskold/marty@mysql.com/linux.site's avatar
      Merge from 5.0 · 6c8f5c58
      mskold/marty@mysql.com/linux.site authored
      6c8f5c58
    • mskold/marty@mysql.com/linux.site's avatar
      Bug #26242 UPDATE with subquery and triggers failing with cluster tables · 625a2629
      mskold/marty@mysql.com/linux.site authored
      In certain cases AFTER UPDATE/DELETE triggers on NDB tables that referenced
      subject table didn't see the results of operation which caused invocation
      of those triggers. In other words AFTER trigger invoked as result of update
      (or deletion) of particular row saw version of this row before update (or
      deletion).
      
      The problem occured because NDB handler in those cases postponed actual
      update/delete operations to be able to perform them later as one batch.
      
      This fix solves the problem by disabling this optimization for particular
      operation if subject table has AFTER trigger for this operation defined.
      To achieve this we introduce two new flags for handler::extra() method:
      HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH.
      These are called if there exists AFTER DELETE/UPDATE triggers during a
      statement that potentially can generate calls to delete_row()/update_row().
      This includes multi_delete/multi_update statements as well as insert statements
      that do delete/update as part of an ON DUPLICATE statement.
      625a2629
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #23675 Partitions: possible security breach via alter · f55ab9ef
      holyfoot/hf@mysql.com/hfmain.(none) authored
      now we return different error message if user doesn't have
      SELECT grants
      f55ab9ef
  14. 03 Apr, 2007 3 commits
  15. 02 Apr, 2007 1 commit
  16. 27 Mar, 2007 3 commits
  17. 24 Mar, 2007 2 commits
  18. 23 Mar, 2007 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Removed not used define YY_MAGIC_BELOW · 19336036
      monty@mysql.com/narttu.mysql.fi authored
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
      19336036
  19. 16 Mar, 2007 4 commits
    • serg@janus.mylan's avatar
      wl#3700 - post-review fixes: · 68fd66e8
      serg@janus.mylan authored
      s/ulonglong/key_part_map/, comments
      68fd66e8
    • joerg@trift2.'s avatar
      Bug#20166 mysql-test-run.pl does not test system privilege tables creation · 66960bd1
      joerg@trift2. authored
       - Build sql files for netware from the mysql_system_tables*.sq files
       - Fix comments about mysql_create_system_tables.sh
       - Use mysql_install_db.sh to create system tables for mysql_test-run-shell
       - Fix mysql-test-run.pl to also look in share/mysql for the msyql_system*.sql files
      
      Changeset coded today by Magnus Svensson, just the application to 5.0.38 is by Joerg Bruehe.
      66960bd1
    • msvensson@pilot.blaudden's avatar
      Bug#20166 mysql-test-run.pl does not test system privilege tables creation · 88b4c86e
      msvensson@pilot.blaudden authored
       - Build sql files for netware from the mysql_system_tables*.sq files
       - Fix comments about mysql_create_system_tables.sh
       - Use mysql_install_db.sh to create system tables for mysql_test-run-shell
       - Fix mysql-test-run.pl to also look in share/mysql for the msyql_system*.sql files
      88b4c86e
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #26261: · 61d93679
      gkodinov/kgeorge@macbook.gmz authored
       INSERT uses query_id to verify what fields are
       mentioned in the fields list of the INSERT command.
       However the check for that is made after the 
       ON DUPLICATE KEY is processed. This causes all
       the fields mentioned in ON DUPLICATE KEY to be 
       considered as mentioned in the fields list of 
       INSERT.
       Moved the check up, right after processing the
       fields list.
      61d93679
  20. 09 Mar, 2007 2 commits
    • guilhem@gbichot3.local's avatar
      Fix for BUG#735 "Prepared Statements: there is no support for Query · eaf7728d
      guilhem@gbichot3.local authored
      Cache".
      WL#1569 "Prepared Statements: implement support of Query Cache".
      Prepared SELECTs did not look up in the query cache, and their results
      were not stored in the query cache. This made them slower than
      non-prepared SELECTs in some cases.
      The fix is to re-use the expanded query (the prepared query where
      "?" placeholders are replaced by their values, at execution time)
      for searching/storing in the query cache.
      It works fine for statements prepared via mysql_stmt_prepare(), which
      are the most commonly used and were the scope of this bugfix and WL.
      It works less fine for statements prepared via the SQL command
      PREPARE...FROM, which are still not using the query cache if they
      have at least one parameter (because then the expanded query contains
      names of user variables, and user variables don't work with the
      query cache, even in non-prepared queries).
      Note that results from prepared SELECTs, which are in the binary
      protocol, and results from normal SELECTs, which are in the text
      protocol, ignore each other in the query cache, because a result in the
      binary protocol should never be served to a SELECT expecting the text
      protocol and vice-versa.
      Note, after this patch, bug 25843 starts applying to query cache
      ("changing default database between PREPARE and EXECUTE of statement
      breaks binlog"), we need to fix it.
      eaf7728d
    • kroki/tomash@moonlight.home's avatar
      BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked · c19affef
      kroki/tomash@moonlight.home authored
      The problem was that some facilities (like CONVERT_TZ() function or
      server HELP statement) may require implicit access to some tables in
      'mysql' database.  This access was done by ordinary means of adding
      such tables to the list of tables the query is going to open.
      However, if we issued LOCK TABLES before that, we would get "table
      was not locked" error trying to open such implicit tables.
      
      The solution is to treat certain tables as MySQL system tables, like
      we already do for mysql.proc.  Such tables may be opened for reading
      at any moment regardless of any locks in effect.  The cost of this is
      that system table may be locked for writing only together with other
      system tables, it is disallowed to lock system tables for writing and
      have any other lock on any other table.
      
      After this patch the following tables are treated as MySQL system
      tables:
        mysql.help_category
        mysql.help_keyword
        mysql.help_relation
        mysql.help_topic
        mysql.proc (it already was)
        mysql.time_zone
        mysql.time_zone_leap_second
        mysql.time_zone_name
        mysql.time_zone_transition
        mysql.time_zone_transition_type
      
      These tables are now opened with open_system_tables_for_read() and
      closed with close_system_tables(), or one table may be opened with
      open_system_table_for_update() and closed with close_thread_tables()
      (the latter is used for mysql.proc table, which is updated as part of
      normal MySQL server operation).  These functions may be used when
      some tables were opened and locked already.
      
      NOTE: online update of time zone tables is not possible during
      replication, because there's no time zone cache flush neither on LOCK
      TABLES, nor on FLUSH TABLES, so the master may serve stale time zone
      data from cache, while on slave updated data will be loaded from the
      time zone tables.
      c19affef
  21. 05 Mar, 2007 3 commits
    • gkodinov/kgeorge@macbook.gmz's avatar
      WL#3527: Extend IGNORE INDEX so places where index is ignored · b9c82eaa
      gkodinov/kgeorge@macbook.gmz authored
               can be specified
      Currently MySQL allows one to specify what indexes to ignore during
      join optimization. The scope of the current USE/FORCE/IGNORE INDEX 
      statement is only the FROM clause, while all other clauses are not 
      affected.
      
      However, in certain cases, the optimizer
      may incorrectly choose an index for sorting and/or grouping, and
      produce an inefficient query plan.
      
      This task provides the means to specify what indexes are
      ignored/used for what operation in a more fine-grained manner, thus
      making it possible to manually force a better plan. We do this
      by extending the current IGNORE/USE/FORCE INDEX syntax to:
      
      IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
      
      so that:
      - if no FOR is specified, the index hint will apply everywhere.
      - if MySQL is started with the compatibility option --old_mode then
        an index hint without a FOR clause works as in 5.0 (i.e, the 
        index will only be ignored for JOINs, but can still be used to
        compute ORDER BY).
      
      See the WL#3527 for further details.
      b9c82eaa
    • msvensson@pilot.blaudden's avatar
      9a2eea40
    • igor@olga.mysql.com's avatar
      Fixed bug #26560. · 08efa4e0
      igor@olga.mysql.com authored
      The flag alias_name_used was not set on for the outer references
      in subqueries. It resulted in replacement of any outer reference
      resolved against an alias for a full field name when the frm 
      representation of a view with a subquery was generated. 
      If the subquery and the outer query referenced the same table in
      their from lists this replacement effectively changed the meaning
      of the view and led to wrong results for selects from this view. 
      
      Modified several functions to ensure setting the right value of
      the alias_name_used flag for outer references resolved against
      aliases.
       
      08efa4e0
  22. 02 Mar, 2007 1 commit
    • antony@ppcg5.local's avatar
      WL#2936 · dc24473c
      antony@ppcg5.local authored
        "Server Variables for Plugins"
        Implement support for plugins to declare server variables.
        Demonstrate functionality by removing InnoDB specific code from sql/*
        New feature for HASH - HASH_UNIQUE flag
        New feature for DYNAMIC_ARRAY - initializer accepts preallocated ptr.
        Completed support for plugin reference counting.
      dc24473c
  23. 01 Mar, 2007 2 commits