An error occurred fetching the project authors.
  1. 25 Aug, 2006 1 commit
    • unknown's avatar
      Fix for bug#21795: SP: sp_head::is_not_allowed_in_function() contains · 133d2aa5
      unknown authored
      erroneous check
      
      Problem: Actually there were two problems in the server code. The check
      for SQLCOM_FLUSH in SF/Triggers were not according to the existing
      architecture which uses sp_get_flags_for_command() from sp_head.cc .
      This function was also missing a check for SQLCOM_FLUSH which has a
      problem combined with prelocking. This changeset fixes both of these
      deficiencies as well as the erroneous check in
      sp_head::is_not_allowed_in_function() which was a copy&paste error.
      
      
      mysql-test/r/sp-error.result:
        update result
      mysql-test/r/trigger.result:
        update result
      mysql-test/t/sp-error.test:
        FLUSH can create a problem with prelocking, hence it's disabled.
        There is a better way to check this than a check in the parser.
        Now we use sp_get_flags_for_command() and the error returned is
        different.
      mysql-test/t/trigger.test:
        FLUSH can create a problem with prelocking, hence it's disabled.
        There is a better way to check this than a check in the parser.
        Now we use sp_get_flags_for_command() and the error returned is
        different.
      sql/sp_head.cc:
        FLUSH and RESET are not allowed inside a SF/Trigger.
        Because they don't imply a COMMIT sp_head::HAS_COMMIT_OR_ROLLBACK
        cannot be used. Two new flags were introduced for that reason.
      sql/sp_head.h:
        Don't check m_type as this check is erroneous. This is probably
        a copy and paste error when moving code from somewhere else. Another
        fact which supports this was prefixing the enum value with the name
        of class sp_head.
        
        Adding two new flags HAS_SQLCOM_RESET and HAS_SQLCOM_FLUSH. The values
        are 2048 and 4096 because in the 5.1 branch there are already new flags
        which are with values up-to 1024.
      sql/sql_parse.cc:
        FLUSH can cause a problem with prelocking in SF/Trigger and
        therefore is already disabled. RESET is also disabled because
        is handled by the same code as FLUSH. We won't allow RESET inside
        SF/Trigger at that stage without thorough analysis. The check for
        them is already done in the parser by calling
        is_not_allowed_in_function()
      sql/sql_yacc.yy:
        By listing SQLCOM_FLUSH as command which implies COMMIT
        in sp_get_flags_for_command() the check in sql_yacc.yy is
        obsolete.
      133d2aa5
  2. 23 Aug, 2006 1 commit
    • unknown's avatar
      Fix for BUG#16899: Possible buffer overflow in handling of DEFINER-clause · f96ee72f
      unknown authored
        
      User name (host name) has limit on length. The server code relies on these
      limits when storing the names. The problem was that sometimes these limits
      were not checked properly, so that could lead to buffer overflow.
      
      The fix is to check length of user/host name in parser and if string is too
      long, throw an error.
      
      
      mysql-test/r/grant.result:
        Updated result file.
      mysql-test/r/sp.result:
        Updated result file.
      mysql-test/r/trigger.result:
        Updated result file.
      mysql-test/r/view.result:
        Updated result file.
      mysql-test/t/grant.test:
        Added test for BUG#16899.
      mysql-test/t/sp.test:
        Added test for BUG#16899.
      mysql-test/t/trigger.test:
        Added test for BUG#16899.
      mysql-test/t/view.test:
        Added test for BUG#16899.
      sql/mysql_priv.h:
        Added prototype for new function.
      sql/share/errmsg.txt:
        Added new resources.
      sql/sql_acl.cc:
        Remove outdated checks.
      sql/sql_parse.cc:
        Add a new function for checking string length.
      sql/sql_yacc.yy:
        Check length of user/host name.
      f96ee72f
  3. 19 Aug, 2006 1 commit
    • unknown's avatar
      WL#3432 (Compile the Parser with a --debug --verbose option) · cd2c9eec
      unknown authored
      Corrected build issues : the build can not be conditional.
      to keep a unique source .tar.gz distribution.
      
      
      configure.in:
        Rolling back previous change
      sql/Makefile.am:
        Partially rolling back previous change.
        The build has to be unconditional, for the source .tar.gz distribution
      sql/mysql_priv.h:
        WL#3432 (Compile the Parser with a --debug --verbose option)
      sql/sql_parse.cc:
        WL#3432 (Compile the Parser with a --debug --verbose option)
        
        Moved turn_parser_debug_on to sql_yacc.yy
      sql/sql_yacc.yy:
        WL#3432 (Compile the Parser with a --debug --verbose option)
        
        Moved turn_parser_debug_on to sql_yacc.yy
      cd2c9eec
  4. 17 Aug, 2006 1 commit
    • unknown's avatar
      WL#3432 (Compile the Parser with a --debug --verbose option) · dec9116f
      unknown authored
      Changed the automake build process :
      - ./configure.in
      - ./sql/Makefile.am
      to compile an instrumented parser for debug=yes or debug=full builds
      
      Changed the (primary) runtime invocation of the parser :
      - sql/sql_parse.cc
      to generate bison traces in stderr when the DBUG "parser_debug" flag is set.
      
      
      configure.in:
        WL#3432 (Compile the Parser with a --debug --verbose option)
        
        New Automake condition : MYSQL_CONF_DEBUG
      sql/Makefile.am:
        WL#3432 (Compile the Parser with a --debug --verbose option)
        
        In Debug mode, compile sql_yacc.yy with --debug --verbose
      sql/sql_parse.cc:
        WL#3432 (Compile the Parser with a --debug --verbose option)
        
        Conditionally turn the bison parser debug on at runtime.
      dec9116f
  5. 20 Jul, 2006 1 commit
    • unknown's avatar
      BUG#20975: Incorrect query result for NOT (subquery): · 68698c04
      unknown authored
        Add implementations of Item_func_{nop,not}_all::neg_transformer
      
      
      mysql-test/r/subselect.result:
        BUG#20975: testcase
      mysql-test/t/subselect.test:
        BUG#20975: testcase
      sql/mysql_priv.h:
        Make chooser_compare_func_creator visible in item.h
      68698c04
  6. 19 Jul, 2006 1 commit
    • unknown's avatar
      A fix and a test case for Bug#21002 "Derived table not selecting from a · 0fa250a9
      unknown authored
      "real" table fails in JOINs".
      
      This is a regression caused by the fix for Bug 18444. 
      This fix removed the assignment of empty_c_string to table->db performed 
      in add_table_to_list, as neither me nor anyone else knew what it was 
      there for. Now we know it and it's covered with tests: the only case 
      when a table database name can be empty is when the table is a derived 
      table. The fix puts the assignment back but makes it a bit more explicit.
      
      Additionally, finally drop sp.result.orig which was checked in by mistake. 
      
      
      BitKeeper/deleted/.del-sp.result.orig:
        Delete: mysql-test/r/sp.result.orig
      mysql-test/r/derived.result:
        Updated result file.
      mysql-test/r/sp.result:
        Test results fixed (Bug#21002)
      mysql-test/t/derived.test:
        New error return for the case when MULTI-DELETE tries to delete from
        a derived table: now derived tables belong to their own db (""), and
        MUTLI-DELETE can't find the correspondent table for it in the 
        DELETE list, as it can't resolve tables in different dbs by alias
        (See Bug#21148 for details)
      mysql-test/t/sp.test:
        Add a test case for Bug#21002 "Derived table not selecting from a "real"
         table fails in JOINs"
      sql/sp.cc:
        Make empty_c_string globally accessible.
      sql/sql_class.cc:
        Add empty_c_string definition.
      sql/sql_class.h:
        Add a comment for the constructor of Table_ident which is
        used for derived tables. Make sure this constructor also initializes
        the database name, not only the table name.
      sql/sql_parse.cc:
        Don't call check_db_name for empty database. 
        Currently the only case when a table database name can be empty
        is when the table is a derived table.
        Report the right error if the database name is wrong (ER_WRONG_DB_NAME,
        not ER_WRONG_TABLE_NAME).
      0fa250a9
  7. 18 Jul, 2006 1 commit
  8. 13 Jul, 2006 1 commit
    • unknown's avatar
      Bug#18630: Arguments of suid routine calculated in wrong security · 06bf59ad
      unknown authored
                 context.
      
      Routine arguments were evaluated in the security context of the routine
      itself, not in the caller's context.
      
      The bug is fixed the following way:
      
        - Item_func_sp::find_and_check_access() has been split into two
          functions: Item_func_sp::find_and_check_access() itself only
          finds the function and check that the caller have EXECUTE privilege
          on it.  New function set_routine_security_ctx() changes security
          context for SUID routines and checks that definer have EXECUTE
          privilege too.
      
        - new function sp_head::execute_trigger() is called from
          Table_triggers_list::process_triggers() instead of
          sp_head::execute_function(), and is effectively just as the
          sp_head::execute_function() is, with all non-trigger related code
          removed, and added trigger-specific security context switch.
      
        - call to Item_func_sp::find_and_check_access() stays outside
          of sp_head::execute_function(), and there is a code in
          sql_parse.cc before the call to sp_head::execute_procedure() that
          checks that the caller have EXECUTE privilege, but both
          sp_head::execute_function() and sp_head::execute_procedure() call
          set_routine_security_ctx() after evaluating their parameters,
          and restore the context after the body is executed.
      
      
      mysql-test/r/sp-security.result:
        Add test case for bug#18630: Arguments of suid routine calculated
        in wrong security context.
      mysql-test/t/sp-security.test:
        Add result for bug#18630: Arguments of suid routine calculated
        in wrong security context.
      sql/item_func.cc:
        Do not change security context before executing the function, as it
        will be changed after argument evaluation.
        Do not change security context in Item_func_sp::find_and_check_access().
      sql/item_func.h:
        Change prototype for Item_func_sp::find_and_check_access().
      sql/sp_head.cc:
        Add set_routine_security_ctx() function.
        Add sp_head::execute_trigger() method.
        Change security context in sp_head::execute_trigger(), and in
        sp_head::execute_function() and sp_head::execute_procedure()
        after argument evaluation.
        Move pop_all_cursors() call to sp_head::execute().
      sql/sp_head.h:
        Add declaration for sp_head::execute_trigger() and
        set_routine_security_ctx().
      sql/sql_parse.cc:
        Do not change security context before executing the procedure, as it
        will be changed after argument evaluation.
      sql/sql_trigger.cc:
        Call new sp_head::execute_trigger() instead of
        sp_head::execute_function(), which is responsible to switch
        security context.
      06bf59ad
  9. 04 Jul, 2006 1 commit
    • unknown's avatar
      A fix and a test case for Bug#17843 "Certain stored procedures fail to · c12cc90d
      unknown authored
      run at startup"
      
      The server returned an error when trying to execute init-file with a 
      stored procedure that could return multiple result sets to the client. 
      A stored procedure can return multiple result sets if it contains 
      PREPARE, SELECT, SHOW and similar statements.
         
      The fix is to set client_capabilites|=CLIENT_MULTI_RESULTS in
      sql_parse.cc:handle_bootstrap(). There is no "client" really, so 
      nothing is ever sent. This makes init-file feature behave consistently: 
      the prepared statements that can be called directly in the init-file 
      can be used in a stored procedure too.
      
      Re-committed the patch originally submitted by Per-Erik after review.
      
      
      mysql-test/Makefile.am:
        Fix re-make without make clean.
      mysql-test/r/init_connect.result:
        Updated results (a test case for Bug#17843)
      mysql-test/r/init_file.result:
        Updated results (a test case for Bug#17843)
      mysql-test/std_data/init_file.dat:
        Add test coverage for new features added in 5.0. Note, that what can 
        be done in init_file is very limited as it does not support any other
        delimiter except ';' -- only "one liners" and no multiple statement 
        procedures. Also, this is executed with a dummy user "boot@", which 
        calls for the use of DEFINER clause.
      mysql-test/t/init_connect.test:
        Add test coverage for new features added in 5.0.
      mysql-test/t/init_file.test:
        Add test coverage for new features added in 5.0 --
        stored routines, views, triggers. The actual tests are in 
        std_data/init_file.dat, here we just check the results and clean up.
      sql/sql_class.cc:
        Initialize Security_context::priv_host to an empty string:
        when executing an init-file, sql_parse.cc:get_default_definer()
        will use this for the value of the definer if it's not set in the query.
      sql/sql_parse.cc:
        Set CLIENT_MULTI_RESULTS in handle_bootstrap(), to make prepared
        statements work in stored procedures called from init-file.
      c12cc90d
  10. 03 Jul, 2006 1 commit
  11. 01 Jul, 2006 1 commit
    • unknown's avatar
      Fix for bug#18437 "Wrong values inserted with a before update trigger on · ae9724cc
      unknown authored
      NDB table".
      
      SQL-layer was not marking fields which were used in triggers as such. As
      result these fields were not always properly retrieved/stored by handler
      layer. So one might got wrong values or lost changes in triggers for NDB,
      Federated and possibly InnoDB tables.
      This fix solves the problem by marking fields used in triggers
      appropriately.
      
      Also this patch contains the following cleanup of ha_ndbcluster code:
      
      We no longer rely on reading LEX::sql_command value in handler in order
      to determine if we can enable optimization which allows us to handle REPLACE
      statement in more efficient way by doing replaces directly in write_row()
      method without reporting error to SQL-layer.
      Instead we rely on SQL-layer informing us whether this optimization
      applicable by calling handler::extra() method with
      HA_EXTRA_WRITE_CAN_REPLACE flag.
      As result we no longer apply this optimzation in cases when it should not
      be used (e.g. if we have on delete triggers on table) and use in some
      additional cases when it is applicable (e.g. for LOAD DATA REPLACE).
      
      Finally this patch includes fix for bug#20728 "REPLACE does not work
      correctly for NDB table with PK and unique index".
        
      This was yet another problem which was caused by improper field mark-up.
      During row replacement fields which weren't explicity used in REPLACE
      statement were not marked as fields to be saved (updated) so they have
      retained values from old row version. The fix is to mark all table
      fields as set for REPLACE statement. Note that in 5.1 we already solve
      this problem by notifying handler that it should save values from all
      fields only in case when real replacement happens.
      
      
      include/my_base.h:
        Added HA_EXTRA_WRITE_CAN_REPLACE, HA_EXTRA_WRITE_CANNOT_REPLACE - new
        parameters for ha_extra() method. We use them to inform handler that
        write_row() which tries to insert new row into the table and encounters
        some already existing row with same primary/unique key can replace old
        row with new row instead of reporting error.
      mysql-test/r/federated.result:
        Additional test for bug#18437 "Wrong values inserted with a before update
        trigger on NDB table".
      mysql-test/r/ndb_replace.result:
        Added test for bug #20728 "REPLACE does not work correctly for NDB table
        with PK and unique index". Updated wrong results from older test.
      mysql-test/t/federated.test:
        Additional test for bug#18437 "Wrong values inserted with a before update
        trigger on NDB table".
      mysql-test/t/ndb_replace.test:
        Added test for bug #20728 "REPLACE does not work correctly for NDB table
        with PK and unique index".
      sql/ha_ndbcluster.cc:
        We no longer rely on reading LEX::sql_command value in handler in order
        to determine if we can enable optimization which allows us to handle REPLACE
        statement in more efficient way by doing replaces directly in write_row()
        method without reporting error to SQL-layer.
        Instead we rely on SQL-layer informing us whether this optimization
        applicable by calling handler::extra() method with
        HA_EXTRA_WRITE_CAN_REPLACE flag.
        As result we no longer apply this optimization in cases when it should not
        be used (e.g. if we have on delete triggers on table) and use in some
        additional cases when it is applicable (e.g. for LOAD DATA REPLACE).
      sql/item.cc:
        Item_trigger_field::setup_field():
          Added comment explaining why we don't set Field::query_id in this method.
      sql/mysql_priv.h:
        mysql_alter_table() function no longer takes handle_duplicates argument.
        Added declaration of mark_fields_used_by_triggers_for_insert_stmt() function.
      sql/sql_delete.cc:
        Mark fields which are used by ON DELETE triggers so handler will retrieve
        values for these fields.
      sql/sql_insert.cc:
        Explicitly inform handler that we are doing REPLACE (using ha_extra() method)
        in cases when it can promote insert operation done by write_row() to replace.
        Also when we do REPLACE we want to store values for all columns so we should
        inform handler about it.
        Finally we should mark fields used by ON UPDATE/ON DELETE triggers as such
        so handler can properly retrieve/restore values in these fields during
        execution of REPLACE and INSERT ... ON DUPLICATE KEY UPDATE statements.
      sql/sql_load.cc:
        Explicitly inform handler that we are doing LOAD DATA REPLACE (using
        ha_extra() method) in cases when it can promote insert operation done by
        write_row() to replace.
        Also when we do replace we want to save (replace) values for all columns
        so we should inform handler about it.
        Finally to properly execute LOAD DATA for table with triggers we should
        mark fields used by ON INSERT triggers as such so handler can properly
        store values for these fields.
      sql/sql_parse.cc:
        mysql_alter_table() function no longer takes handle_duplicates argument.
      sql/sql_table.cc:
        Got rid of handle_duplicates argument in mysql_alter_table() and
        copy_data_between_tables() functions. These functions were always
        called with handle_duplicates == DUP_ERROR and thus contained dead
        (and probably incorrect) code.
      sql/sql_trigger.cc:
        Added Table_triggers_list::mark_fields_used() method which is used to mark
        fields read/set by triggers as such so handlers will be able properly
        retrieve/store values in these fields.
      sql/sql_trigger.h:
        Table_triggers_list:
          Added mark_fields_used() method which is used to mark fields read/set by
          triggers as such so handlers will be able properly retrieve/store values
          in these fields. To implement this method added 'trigger_fields' member
          which is array of lists linking items for all fields used in triggers
          grouped by event and action time.
      sql/sql_update.cc:
        Mark fields which are used by ON UPDATE triggers so handler will retrieve
        and save values for these fields.
      mysql-test/r/ndb_trigger.result:
        Added test for bug#18437 "Wrong values inserted with a before update trigger
        on NDB table".
      mysql-test/t/ndb_trigger.test:
        Added test for bug#18437 "Wrong values inserted with a before update trigger
        on NDB table".
      ae9724cc
  12. 30 Jun, 2006 1 commit
    • unknown's avatar
      Remove a couple of unused/barely used names. · 0c7bc6e9
      unknown authored
      sql/sql_lex.cc:
        Remove an unused thread key.
      sql/sql_lex.h:
        Remove an unused thread key, current_lex.
      sql/sql_parse.cc:
        Remove an unused thread key, current_lex macro.
      0c7bc6e9
  13. 29 Jun, 2006 1 commit
    • unknown's avatar
      Bug#15298 SHOW GRANTS FOR CURRENT_USER: Incorrect output in DEFINER context · 728371c5
      unknown authored
      user name is calculated on function execution stage instead of parse stage
      
      
      mysql-test/r/sp_notembedded.result:
        Bug#15298 SHOW GRANTS FOR CURRENT_USER: Incorrect output in DEFINER context
        test case
      mysql-test/t/sp_notembedded.test:
        Bug#15298 SHOW GRANTS FOR CURRENT_USER: Incorrect output in DEFINER context
        test case
      sql/mysql_priv.h:
        Bug#15298 SHOW GRANTS FOR CURRENT_USER: Incorrect output in DEFINER context
        new get_current_user(THD *thd, LEX_USER *user) function
      sql/sql_acl.cc:
        Bug#15298 SHOW GRANTS FOR CURRENT_USER: Incorrect output in DEFINER context
        user name is calculated using get_current_user() function
      sql/sql_parse.cc:
        Bug#15298 SHOW GRANTS FOR CURRENT_USER: Incorrect output in DEFINER context
        new get_current_user() function
        user name is calculated using get_current_user() function
      sql/sql_yacc.yy:
        Bug#15298 SHOW GRANTS FOR CURRENT_USER: Incorrect output in DEFINER context
        empty LEX_USER struct for CURRENT USER, 
        user name is calculated on function execution stage
      728371c5
  14. 27 Jun, 2006 1 commit
    • unknown's avatar
      BUG#1662 - ALTER TABLE LIKE ignores DATA/INDEX DIRECTPORY · f4a07612
      unknown authored
      Produce a warning if DATA/INDEX DIRECTORY is specified in
      ALTER TABLE statement.
      
      Ignoring of these options is documented in the symbolic links
      section of the manual.
      
      
      mysql-test/r/symlink.result:
        Modified test result according to fix for BUG#1662.
      sql/sql_parse.cc:
        Produce a warning if DATA/INDEX DIRECTORY is specified in
        ALTER TABLE statement.
      f4a07612
  15. 26 Jun, 2006 2 commits
    • unknown's avatar
      A fix and a test case for · d6bcbfbe
      unknown authored
       Bug#19022 "Memory bug when switching db during trigger execution"
       Bug#17199 "Problem when view calls function from another database."
       Bug#18444 "Fully qualified stored function names don't work correctly in
                  SELECT statements"
      
       Documentation note: this patch introduces a change in behaviour of prepared
       statements.
      
       This patch adds a few new invariants with regard to how THD::db should
       be used. These invariants should be preserved in future:
      
        - one should never refer to THD::db by pointer and always make a deep copy
          (strmake, strdup)
        - one should never compare two databases by pointer, but use strncmp or
          my_strncasecmp
        - TABLE_LIST object table->db should be always initialized in the parser or
          by creator of the object.
      
          For prepared statements it means that if the current database is changed
          after a statement is prepared, the database that was current at prepare
          remains active. This also means that you can not prepare a statement that
          implicitly refers to the current database if the latter is not set.
          This is not documented, and therefore needs documentation. This is NOT a
          change in behavior for almost all SQL statements except:
           - ALTER TABLE t1 RENAME t2 
           - OPTIMIZE TABLE t1
           - ANALYZE TABLE t1
           - TRUNCATE TABLE t1 --
           until this patch t1 or t2 could be evaluated at the first execution of
           prepared statement. 
      
           CURRENT_DATABASE() still works OK and is evaluated at every execution
           of prepared statement.
      
           Note, that in stored routines this is not an issue as the default
           database is the database of the stored procedure and "use" statement
           is prohibited in stored routines.
      
        This patch makes obsolete the use of check_db_used (it was never used in the
        old code too) and all other places that check for table->db and assign it
        from THD::db if it's NULL, except the parser.
      
       How this patch was created: THD::{db,db_length} were replaced with a
       LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
       manually checked and:
        - if the place uses thd->db by pointer, it was fixed to make a deep copy
        - if a place compared two db pointers, it was fixed to compare them by value
          (via strcmp/my_strcasecmp, whatever was approproate)
       Then this intermediate patch was used to write a smaller patch that does the
       same thing but without a rename.
      
       TODO in 5.1:
         - remove check_db_used
         - deploy THD::set_db in mysql_change_db
      
       See also comments to individual files.
      
      
      mysql-test/r/create.result:
        Modify the result file: a database can never be NULL.
      mysql-test/r/ps.result:
        Update test results (Bug#17199 et al)
      mysql-test/r/sp.result:
        Update test results (Bug#17199 et al)
      mysql-test/t/create.test:
        Update the id of the returned error.
      mysql-test/t/ps.test:
        Add test coverage for prepared statements and current database. In scope of
        work on Bug#17199 "Problem when view calls function from another database."
      mysql-test/t/sp.test:
        Add a test case for Bug#17199 "Problem when view calls function from another
        database." and Bug#18444 "Fully qualified stored function names don't work
        correctly in SELECT statements". Test a complementary problem.
      sql/item_strfunc.cc:
        Touch the code that reads thd->db (cleanup).
      sql/log_event.cc:
        While we are at it, replace direct access to thd->db with a method.
        Should simplify future conversion of THD::db to LEX_STRING.
      sql/slave.cc:
        While we are at it, replace direct access to thd->db with a method.
        Should simplify future conversion of THD::db to LEX_STRING.
      sql/slave.h:
        Remove a declaration for a method that is used only in one module.
      sql/sp.cc:
        Rewrite sp_use_new_db: this is a cleanup that I needed in order to understand
        this function and ensure that it has no bugs.
      sql/sp.h:
        Add a new declaration for sp_use_new_db (uses LEX_STRINGs) and a comment.
      sql/sp_head.cc:
        - drop sp_name_current_db_new - a creator of sp_name class that was used
        when sp_name was created for an identifier without an explicitly initialized
        database. Now we pass thd->db to constructor of sp_name right in the 
        parser.
        - rewrite sp_head::init_strings: name->m_db is always set now
        - use the new variant of sp_use_new_db
        - we don't need to update thd->db with SP MEM_ROOT pointer anymore when
        parsing a stored procedure, as noone will refer to it (yes!)
      sql/sp_head.h:
        - remove unneded methods and members
      sql/sql_class.h:
        - introduce 3 THD  methods to work with THD::db:
          .set_db to assign the current database
          .reset_db to reset the current database (temporarily) or set it to NULL
          .opt_copy_db_to - to deep-copy thd->db to a pointer if it's not NULL
      sql/sql_db.cc:
        While we are at it, replace direct access to thd->db with a method.
        Should simplify future conversion of THD::db to LEX_STRING.
      sql/sql_insert.cc:
        - replace checks with asserts: table_list->db must be always set in the parser.
      sql/sql_lex.h:
        - add a comment
      sql/sql_parse.cc:
        - implement the invariant described in the changeset comment.
        - remove juggling with lex->sphead in SQLCOM_CREATE_PROCEDURE:
          now db_load_routine uses its own LEX object and doesn't damage the main
          LEX.
        - add DBUG_ASSERT(0) to unused "check_db_used"
      sql/sql_table.cc:
        - replace a check with an assert (table_ident->db)
      sql/sql_trigger.cc:
        While we are at it, replace direct access to thd->db with a method.
        Should simplify future conversion of THD::db to LEX_STRING.
      sql/sql_udf.cc:
        - use thd->set_db instead of direct modification of to thd->db
      sql/sql_view.cc:
        - replace a check with an assert (view->db)
      sql/sql_yacc.yy:
        - make sure that we always copy table->db or name->db or ident->db or
          select_lex->db from thd->db if the former is not set. If thd->db
          is not set but is accessed, return an error.
      sql/tztime.cc:
        - be nice, never copy thd->db by pointer.
      d6bcbfbe
    • unknown's avatar
      Bug#16986 - Deadlock condition with MyISAM tables · 1c2a13b8
      unknown authored
      Addendum fixes after changing the condition variable
      for the global read lock.
      
      The stress test suite revealed some deadlocks. Some were
      related to the new condition variable (COND_global_read_lock)
      and some were general problems with the global read lock.
      
      It is now necessary to signal COND_global_read_lock whenever 
      COND_refresh is signalled.
      
      We need to wait for the release of a global read lock if one 
      is set before every operation that requires a write lock.
      But we must not wait if we have locked tables by LOCK TABLES.
      After setting a global read lock a thread waits until all
      write locks are released.
      
      
      mysql-test/r/lock_multi.result:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Added test results.
      mysql-test/t/lock_multi.test:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Added tests for possible deadlocks that did not occur
        with the stress test suite.
      mysys/thr_lock.c:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Added a protection against an infinite loop that occurs
        with the test case for Bug #20662.
      sql/lock.cc:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Signal COND_global_read_lock whenever COND_refresh
        is signalled by using the new function broadcast_refresh().
        Added the definition of a new function that signals 
        COND_global_read_lock whenever COND_refresh is signalled.
      sql/mysql_priv.h:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Added a declaration for a new function that signals 
        COND_global_read_lock whenever COND_refresh is signalled.
      sql/sql_base.cc:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Signal COND_global_read_lock whenever COND_refresh
        is signalled by using the new function broadcast_refresh().
      sql/sql_handler.cc:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Signal COND_global_read_lock whenever COND_refresh
        is signalled by using the new function broadcast_refresh().
      sql/sql_insert.cc:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Removed global read lock handling from inside of 
        INSERT DELAYED. It is handled on a higher level now.
      sql/sql_parse.cc:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Wait for the release of a global read lock if one is set
        before every operation that requires a write lock.
        But don't wait if locked tables exist already.
      sql/sql_table.cc:
        Bug#16986 - Deadlock condition with MyISAM tables
        Addendum fixes after changing the condition variable
        for the global read lock.
        Removed global read lock handling from inside of 
        CREATE TABLE. It is handled on a higher level now.
        Signal COND_global_read_lock whenever COND_refresh
        is signalled by using the new function broadcast_refresh().
      1c2a13b8
  16. 21 Jun, 2006 1 commit
    • unknown's avatar
      Bug #20482: failure on Create join view with sources views/tables in different · 6c787151
      unknown authored
                  schemas
      The function check_one_table_access() called to check access to tables in 
      SELECT/INSERT/UPDATE was doing additional checks/modifications that don't hold
      in the context of setup_tables_and_check_access().
      That's why the check_one_table() was split into two : the functionality needed by
      setup_tables_and_check_access() into check_single_table_access() and the rest of 
      the functionality stays in check_one_table_access() that is made to call the new
      check_single_table_access() function.
      
      
      mysql-test/r/view_grant.result:
        Bug #20482: failure on Create join view with sources views/tables in different 
                    schemas
        - test suite for the bug
      mysql-test/t/view_grant.test:
        Bug #20482: failure on Create join view with sources views/tables in different 
                    schemas
        - test suite for the bug
      sql/mysql_priv.h:
        Bug #20482: failure on Create join view with sources views/tables in different 
                    schemas
        - check_one_table_access split into 2
      sql/sql_base.cc:
        Bug #20482: failure on Create join view with sources views/tables in different 
                    schemas
        - the new sub-function called
      sql/sql_parse.cc:
        Bug #20482: failure on Create join view with sources views/tables in different 
                    schemas
        - check_one_table_access() split into two : check_single_table_access() to 
          actually check access to the table(ro) and check_one_table_access() that calls
          check_single_table_access() and checks also the tables belonging to sub selects
          or implicitly opened tables.
      6c787151
  17. 20 Jun, 2006 1 commit
    • unknown's avatar
      Fix for bug#19634 "Re-execution of multi-delete which involve trigger/stored · e9452db1
      unknown authored
      function crashes server".
      
      Attempts to execute prepared multi-delete statement which involved trigger or
      stored function caused server crashes (the same happened for such statements
      included in stored procedures in cases when one tried to execute them more
      than once).
      
      The problem was caused by yet another incorrect usage of check_table_access()
      routine (the latter assumes that table list which it gets as argument
      corresponds to value LEX::query_tables_own_last). We solve this problem by
      juggling with LEX::query_tables_own_last value when we call
      check_table_access() for LEX::auxilliary_table_list (better solution is too
      intrusive and should be done in 5.1).
      
      
      mysql-test/r/sp-prelocking.result:
        Added test for bug#19634 "Re-execution of multi-delete which involve trigger/
        stored function crashes server".
      mysql-test/t/sp-prelocking.test:
        Added test for bug#19634 "Re-execution of multi-delete which involve trigger/
        stored function crashes server".
      sql/sql_parse.cc:
        To call safely check_table_access() for LEX::auxilliary_table_list we have
        to juggle with LEX::query_tables_own_last value.
      e9452db1
  18. 19 Jun, 2006 2 commits
    • unknown's avatar
      bug #20318 (ctype_ucs2_def test fails with embedded) · 8b6c2d31
      unknown authored
      there was two problems about charsets in embedded server
      1. mysys/charset.c - defined there default_charset_info variable is
      modified by both server and client code (particularly when
      --default-charset option is handled)
      In embedded server we get two codelines modifying one variable.
      I created separate default_client_charset_info for client code
      
      2. mysql->charset and mysql->options.charset initialization isn't
      properly done for embedded server - necessary calls added
      
      
      include/sql_common.h:
        client charset info default declared
      libmysqld/lib_sql.cc:
        thd_init_client_charset calls added
      libmysqld/libmysqld.c:
        check_embedded_connection moved to client.c to avoid code duplication
      sql-common/client.c:
        charset initialization moved to mysql_init_character_set to
        be used in embedded server
      sql/sql_parse.cc:
        thread client charset initialization moved to thd_init_client_charset
        to avoid code duplication
      8b6c2d31
    • unknown's avatar
      Bug #18080: INSERT ... SELECT ... JOIN results in ambiguous field list error · b7e27e80
      unknown authored
      There was an incomplete reset of the name resolution context, that caused 
      INSERT ... SELECT ... JOIN statements to resolve not by joint row type calculated
      for the join.
      Removed the redundant re-initialization of the context, because 
      mysql_insert_select_prepare() now correctly saves/restores the context.
      
      
      mysql-test/r/insert_select.result:
        Bug #18080: INSERT ... SELECT ... JOIN results in ambiguous field list error
        
        - testsuite for the bug
      mysql-test/t/insert_select.test:
        Bug #18080: INSERT ... SELECT ... JOIN results in ambiguous field list error
        
        - testsuite for the bug
      sql/sql_parse.cc:
        Bug #18080: INSERT ... SELECT ... JOIN results in ambiguous field list error
        
        - remove an incomplete reset of the context because the mentioned function
        correctly saves/restores the context.
      b7e27e80
  19. 12 Jun, 2006 1 commit
    • unknown's avatar
      Bug #20363: Create view on just created view is now denied · e7daa497
      unknown authored
      There was a wrong determination of the DB name (witch is 
      not always the one in TABLE_LIST because derived tables
      may be calculated using temp tables that have their db name
      set to "").
      The fix determines the database name according to the type 
      of table reference, and calls the function check_access() 
      with the correct db name so the correct set of grants is found.
      
      
      mysql-test/r/view_grant.result:
        testsuite for the bug
      mysql-test/t/view_grant.test:
        testsuite for the bug
      sql/sql_parse.cc:
        correct determination of the db name.
      e7daa497
  20. 01 Jun, 2006 1 commit
    • unknown's avatar
      bug #16017 (memory leaks in embedded server) · eadcf200
      unknown authored
      There actually was 3 different problems -
      hash_user_connections wasn't cleaned
      one strdupped database name wasn't freed
      and stmt->mem_root wasn't cleaned as it was
      replased with mysql->field_alloc for result
      For the last one - i made the library using stmt's
      fields to store result if it's the case.
      
      
      include/mysql.h:
        statement pointer added to the advanced_command to be checked in
        embedded server
      include/sql_common.h:
        stmt added to the cli_advanced_command interface
      libmysql/libmysql.c:
        stmt pointer now sent to advanced_command
      libmysqld/embedded_priv.h:
        it's enough to send database name to check_embedded_connection
      libmysqld/lib_sql.cc:
        Now we store result directly in the MYSQL_STMT structure to
        avoid extra copying
      libmysqld/libmysqld.c:
        it's enough to only send database pointer to check_embedded_connection
      sql-common/client.c:
        stmt fake attribute added to cli_advanced_command
      sql/sql_parse.cc:
        hash_user_connections isn't used if no access checks compiled
      eadcf200
  21. 28 May, 2006 1 commit
    • unknown's avatar
      Fixed bug#19225: unchecked error results in server crash · 2264b644
      unknown authored
      In multi-table delete a table for delete can't be used for selecting in
      subselects. Appropriate error was raised but wasn't checked which leads to a
      crash at the execution phase.
      
      The mysql_execute_command() now checks for errors before executing select
      for multi-delete.
      
      
      mysql-test/t/multi_update.test:
        Added test case for bug#19225: unchecked error results in server crash
      mysql-test/r/multi_update.result:
        Added test case for bug#19225: unchecked error results in server crash
      sql/sql_parse.cc:
        Fixed bug#19225: unchecked error results in server crash
        The mysql_execute_command() now checks for errors before executing select for multi-delete.
      2264b644
  22. 26 May, 2006 1 commit
    • unknown's avatar
      BUG#18681: View privileges are broken · d7743c41
      unknown authored
      The check for view security was lacking several points :
      1. Check with the right set of permissions : for each table ref that
      participates in a view there were the right credentials to use in it's
      security_ctx member, but these weren't used for checking the credentials.
      This makes hard enforcing the SQL SECURITY DEFINER|INVOKER property
      consistently.
      2. Because of the above the security checking for views was just ruled out
      in explicit ways in several places.
      3. The security was checked only for the columns of the tables that are
      brought into the query from a view. So if there is no column reference
      outside of the view definition it was not detecting the lack of access to
      the tables in the view in SQL SECURITY INVOKER mode.
      
      The fix below tries to fix the above 3 points.
      
      
      mysql-test/r/grant.result:
        removed nondeterminism (unspecified order) in some test output
      mysql-test/r/view_grant.result:
        Somewhat extended test case for the bug and similar queries.
      mysql-test/t/grant.test:
        removed nondeterminism (unspecified order) in some test output
      mysql-test/t/view_grant.test:
        Somewhat extended test case for the bug and similar queries.
      sql/mysql_priv.h:
        A wrapper for setup_tables that also checks access to the tables
      sql/sql_acl.cc:
        removed artificial security check stop and used the table ref's credentials.
      sql/sql_base.cc:
        a wrapper for setup_tables to check access to the tables
      sql/sql_delete.cc:
        wrapper called.
      sql/sql_insert.cc:
        wrapper called
      sql/sql_load.cc:
        wrapper called
      sql/sql_parse.cc:
        wrapper called and artificial check stop removed
      sql/sql_select.cc:
        wrapper called
      sql/sql_update.cc:
        wrapper called
      sql/table.cc:
        Mask table access to the view error as well.
      d7743c41
  23. 24 May, 2006 1 commit
  24. 10 May, 2006 1 commit
    • unknown's avatar
      Follow-up for the patch for bugs #12472/#15137 "CREATE TABLE ... SELECT ... · 82727c62
      unknown authored
      which explicitly or implicitly uses stored function gives 'Table not locked'
      error"
      
      Test case for these bugs crashed in --ps-protocol mode. The crash was caused
      by incorrect usage of check_grant() routine from create_table_precheck()
      routine. The former assumes that either number of tables to be inspected by
      it is limited explicitly (i.e. is is not UINT_MAX) or table list used and
      thd->lex->query_tables_own_last value correspond to each other.
      create_table_precheck() was not fulfilling this condition and crash happened.
      The fix simply sets number of tables to be inspected by check_grant() to 1.
      
      
      sql/sql_parse.cc:
        create_table_precheck():
          At the moment when create_table_precheck() is called TABLE_LIST element
          representing table to be created does not belong to global table list
          therefore we should limit number of tables to be inspected by check_grant()
          explicitly (as in this case table list passed to this function does not
          correspond to thd->lex->query_tables_own_last value).
      82727c62
  25. 06 May, 2006 1 commit
    • unknown's avatar
      Reapply fix for bug#16372 (Server crashes when test 'conc_sys' is running) · 8052fafd
      unknown authored
      after merge.
      
      Concurrent read and update of privilege structures (like simultaneous
      run of SHOW GRANTS and ADD USER) could result in server crash.
      
      Ensure that proper locking of ACL structures is done.
      
      No test case is provided because this bug can't be reproduced
      deterministically.
      
      
      sql/sql_acl.cc:
        Ensure that access to ACL data is protected by acl_cache->lock mutex.
        Use system_charset_info for host names consistently.
        Remove check_acl_user().  Use find_acl_user() instead.
      sql/sql_acl.h:
        Remove check_acl_user() declaration.
      sql/sql_parse.cc:
        Use is_acl_user() instead of check_acl_user().
      8052fafd
  26. 03 May, 2006 1 commit
    • unknown's avatar
      Bug#15463: EXPLAIN SELECT..INTO hangs the client (QB, command line) · bf8dac3b
      unknown authored
      There were two distict bugs: parse error was returned for valid
      statement and that error wasn't reported to the client.
      
      The fix ensures that EXPLAIN SELECT..INTO is accepted by parser and any
      other parse error will be reported to the client.
      
      
      mysql-test/r/explain.result:
        Add result for bug#15463.
      mysql-test/t/explain.test:
        Add test case for bug#15463.
      sql/sql_parse.cc:
        Assert that if parsing error has occured then apropriate error message
        has been pushed into error stack.
      sql/sql_yacc.yy:
        If there is no lex->result in select_var_ident rule, then we have
        to be in DESCRIBE mode.
      bf8dac3b
  27. 02 May, 2006 2 commits
    • unknown's avatar
      sql_parse.cc: · 617f8ac9
      unknown authored
        buffer overflow and information exposure bugs fixed
        (reported by Stefano Di Paola)
      configure.in:
        Changed version to 5.0.17b
      
      
      configure.in:
        Changed version to 5.0.17b
      sql/sql_parse.cc:
        buffer overflow and information exposure bugs fixed
        (reported by Stefano Di Paola)
      617f8ac9
    • unknown's avatar
      SECURITY FIX · 3010890e
      unknown authored
      Bug#17667: An attacker has the opportunity to bypass query logging.
      
      This adds a new, local-only printf format specifier to our *printf functions
      that allows us to print known-size buffers that must not be interpreted as 
      NUL-terminated "strings."
      
      It uses this format-specifier to print to the log, thus fixing this 
      problem.
      
      
      include/my_sys.h:
        Add prototype for my_memmem() .
      mysys/Makefile.am:
        Add reference to new file, my_memmem.c
      mysys/mf_iocache2.c:
        Add a "%.1234b" and "%.*b" percent-code.  It takes a width, just like "%s", 
        but unlike the string-indicator, it requires the width and doesn't stop printing
        at NUL characters.
        
        Also, simplify the code a bit.
        
        TODO:  This code should be unified with the strings/my_vnsprintf.c code in 
        the future.
      sql/sql_parse.cc:
        The query is not a C-string, but is a sized buffer, containing any character 
        at all, which may include NUL characters.
      strings/my_vsnprintf.c:
        Add a "%.1234b" and "%.*b" percent-code.  It takes a width, just like "%s", 
        but unlike the string-indicator, it requires the width and doesn't stop printing
        at NUL characters.
      tests/Makefile.am:
        We may need some of our local functions.
      tests/mysql_client_test.c:
        Add a "%.1234b" and "%.*b" percent-code.  It takes a width, just like "%s", 
        but unlike the string-indicator, it requires the width and doesn't stop printing
        at NUL characters.
      mysql-test/t/mysql_client_test.opt:
        New BitKeeper file ``mysql-test/t/mysql_client_test.opt''
        
        Add '--log' server parameter.
      mysys/my_memmem.c:
        New BitKeeper file ``mysys/my_memmem.c''
        
        Implement memmem, a black-box work-alike of the GNU memmem(), which functions
        like strstr() but for arbitrary blocks of memory.
      3010890e
  28. 26 Apr, 2006 2 commits
  29. 25 Apr, 2006 2 commits
  30. 21 Apr, 2006 2 commits
    • unknown's avatar
      Post merge fixes · b93dd432
      unknown authored
      b93dd432
    • unknown's avatar
      Fixed bug #18767. · 9225a51c
      unknown authored
      The bug caused wrong result sets for union constructs of the form
      (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
      For such queries order lists were concatenated and limit clause was
      completely neglected. 
      
      
      mysql-test/r/order_by.result:
        Added a test case for bug #18767.
      mysql-test/t/order_by.test:
        Added a test case for bug #18767.
      sql/sql_lex.h:
        Fixed bug #18767.
        Placed the code the created a fake SELECT_LEX into a separate function.
      sql/sql_parse.cc:
        Fixed bug #18767.
        Placed the code the created a fake SELECT_LEX into a separate function.
      sql/sql_select.cc:
        Fixed bug #18767.
        Changed the condition on which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence.
      sql/sql_union.cc:
        Fixed bug #18767.
        Changed the condition at which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence.
      sql/sql_yacc.yy:
        Fixed bug #18767.
        Changed the condition at which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence. In the same way is handled the SELECT in
        (SELECT ... LIMIT n) ORDER BY order list.
        Yet if there is neither ORDER BY nor LIMIT in the single-select
        union construct
        (SELECT ...) ORDER BY order_list
        then it is still handled as simple select with an order clause.
      9225a51c
  31. 18 Apr, 2006 1 commit
    • unknown's avatar
      BUG#13310 incorrect user parsing by SP · 3bcbf913
      unknown authored
       - Strip surrounding ''s from username when a new user connects. There
         is no user 'a@', it should be a@
      
      
      mysql-test/r/grant2.result:
        Update test result
      mysql-test/t/grant2.test:
        Add tests for bug 13310
      sql/sql_parse.cc:
        Strip surrounding ''s from username when a new user connects. There 
        is no user 'a@', it should be a@
      3bcbf913
  32. 07 Apr, 2006 1 commit
    • unknown's avatar
      Bug#15933: max_used_connections is wrong after FLUSH STATUS if connections are cached · cab73a60
      unknown authored
      After FLUSH STATUS max_used_connections was reset to 0, and haven't
      been updated while cached threads were reused, until the moment a new
      thread was created.
      
      The first suggested fix from original bug report was implemented:
      
        a) On flushing the status, set max_used_connections to
        threads_connected, not to 0.
      
        b) Check if it is necessary to increment max_used_connections when
        taking a thread from the cache as well as when creating new threads
      
      
      mysql-test/r/status.result:
        Add result for bug#15933.
      mysql-test/t/status.test:
        Add test case for bug#15933.
        Fixed typo.
      sql/mysql_priv.h:
        Add declaration of refresh_status(), which is now external.
      sql/mysqld.cc:
        Remove start_cached_thread() (code moved directly into create_new_thread()).
        Add comment for create_new_thread ().
        In create_new_thread() update max_used_connections when creating new thread
        and when reusing the cached one.
        Move refresh_status() from sql/sql_parse.cc here, on refresh set
        max_used_connections to the current number of connections.
      sql/sql_parse.cc:
        refresh_status() moved to sql/mysqld.cc.
      cab73a60
  33. 06 Apr, 2006 1 commit
    • unknown's avatar
      Fix for bug#14945 "Truncate table doesn't reset the auto_increment · ee3cf23b
      unknown authored
      counter".
      
      When TRUNCATE TABLE was called within an stored procedure the
      auto_increment counter was not reset to 0 even if straight
      TRUNCATE for this table did this.
      
      This fix makes TRUNCATE in stored procedures to be handled exactly
      in the same way as straight TRUNCATE. We achieve this by rolling
      back the fix for bug 8850, which is no longer needed since stored
      procedures don't require prelocked mode anymore (and TRUNCATE is
      not allowed in stored functions or triggers).
      
      
      mysql-test/r/sp.result:
        Test case for BUG#14945.
      mysql-test/t/sp.test:
        Test case for BUG#14945.
      sql/sql_delete.cc:
        Handle TRUNCATE in stored procedures exactly in the same way as straight
        TRUNCATE (i.e. without falling back to DELETE if possible). We achieve
        this by rolling back the fix for bug 8850, which is no longer relevant
        since stored procedures don't require prelocked mode anymore
        (and TRUNCATE is not allowed in stored functions or triggers).
      sql/sql_parse.cc:
        Handle TRUNCATE in stored procedures exactly in the same way as straight
        TRUNCATE (i.e. without falling back to DELETE if possible). We achieve
        this by rolling back the fix for bug 8850, which is no longer relevant
        since stored procedures don't require prelocked mode anymore
        (and TRUNCATE is not allowed in stored functions or triggers).
      ee3cf23b
  34. 15 Mar, 2006 1 commit
    • unknown's avatar
      We should prohobit concurent read of inserting file in SP · bb69d16d
      unknown authored
      because it can couse problem with Query cache (BUG#14767)
      
      
      mysql-test/r/query_cache_notembedded.result:
        BUG#14767 test suite.
      mysql-test/t/query_cache_notembedded.test:
        BUG#14767 test suite.
      sql/sql_insert.cc:
        Query cache invalidation table we was inserting in just after
        unlocking table added to avoid the race condition as we had
        with SP.
      sql/sql_parse.cc:
        Query cache invalidation table we was inserting in just after
        unlocking table added to avoid the race condition as we had
        with SP.
      sql/sql_yacc.yy:
        We should prohibit concurent read of unserting file in SP
        because it can cause problem with query cache.
      bb69d16d