1. 28 Oct, 2009 1 commit
  2. 27 Oct, 2009 4 commits
    • Georgi Kodinov's avatar
      merge from 4.1 · 95dce2b0
      Georgi Kodinov authored
      95dce2b0
    • Sergey Glukhov's avatar
      automerge · 80b79bae
      Sergey Glukhov authored
      80b79bae
    • Sergey Vojtovich's avatar
      An addition to fix for · cf41b43b
      Sergey Vojtovich authored
      BUG#41597 - After rename of user, there are additional grants
                  when grants are reapplied.
      
      Fixed build failure on Windows. Added missing cast.
      cf41b43b
    • Sergey Glukhov's avatar
      Bug#41049 does syntax "grant" case insensitive? · 58b7761e
      Sergey Glukhov authored
      Problem 1:
      column_priv_hash uses utf8_general_ci collation
      for the key comparison. The key consists of user name,
      db name and table name. Thus user with privileges on table t1
      is able to perform the same operation on T1
      (the similar situation with user name & db name, see acl_cache).
      So collation which is used for column_priv_hash and acl_cache
      should be case sensitive.
      The fix:
      replace system_charset_info with my_charset_utf8_bin for
      column_priv_hash and acl_cache
      Problem 2:
      The same situation with proc_priv_hash, func_priv_hash,
      the only difference is that Routine name is case insensitive.
      So the fix is to use my_charset_utf8_bin for
      proc_priv_hash & func_priv_hash and convert routine name into lower
      case before writing the element into the hash and
      before looking up the key.
      Additional fix: mysql.procs_priv Routine_name field collation
      is changed to utf8_general_ci.
      It's necessary for REVOKE command
      (to find a field by routine hash element values).
      Note: 
      It's safe for lower-case-table-names mode too because
      db name & table name are converted into lower case
      (see GRANT_NAME::GRANT_NAME).
      58b7761e
  3. 21 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #47780: crash when comparing GIS items from subquery · dd02c4a1
      Georgi Kodinov authored
            
      If the first argument to GeomFromWKB function is a geometry
      field then the function just returns its value.
      However in doing so it's not preserving first argument's 
      null_value flag and this causes unexpected null value to
      be returned to the calling function.
            
      Fixed by updating the null_value of the GeomFromWKB function
      in such cases (and all other cases that return a NULL e.g.
      because of not enough memory for the return buffer).
      dd02c4a1
  4. 23 Oct, 2009 1 commit
  5. 21 Oct, 2009 2 commits
  6. 20 Oct, 2009 4 commits
    • Georgi Kodinov's avatar
      Bug #47320: OpenSSL client does not check YaSSL server certificate · 90d32d8b
      Georgi Kodinov authored
      Removed the verify callback, as it's not needed to verify even self
      signed certificates and is a security problem.
      90d32d8b
    • Satya B's avatar
      merge to mysql-5.0-bugteam · 607abec5
      Satya B authored
      607abec5
    • Satya B's avatar
      Fix for Bug #41597 - After rename of user, there are additional grants when · b2cd0a0f
      Satya B authored
                           grants are reapplied.
      
      
      After renaming a user and trying to re-apply grants results in additional
      grants.
      
      This is because we use username as part of the key for GRANT_TABLE structure.
      When the user is renamed, we only change the username stored and the hash key
      still contains the old user name and this results in the extra privileges
      
      Fixed by rebuilding the hash key and updating the column_priv_hash structure
      when the user is renamed
      b2cd0a0f
    • Tatiana A. Nurnberg's avatar
      Bug#28141: Control C on query waiting on lock causes ERROR 1053 (server shutdown) · 3f42e4bd
      Tatiana A. Nurnberg authored
      If a thread is killed in the server, we throw "shutdown" only if one is actually in
      progress; otherwise, we throw "query interrupted".
      
      Control-C in the mysql command-line client is "incremental" now.
      First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next)
      Next  Control-C sends KILL CONNECTION
      Next  Control-C aborts client.
      
      As the first two steps only pertain to an existing query,
      Control-C will abort the client right away if no query is running.
      
      client will give more detailed/consistent feedback on Control-C now.
      3f42e4bd
  7. 16 Oct, 2009 3 commits
  8. 15 Oct, 2009 1 commit
  9. 14 Oct, 2009 3 commits
  10. 13 Oct, 2009 1 commit
  11. 08 Oct, 2009 4 commits
  12. 06 Oct, 2009 3 commits
    • Kristofer Pettersson's avatar
      Automerge · 14f76673
      Kristofer Pettersson authored
      14f76673
    • Kristofer Pettersson's avatar
      Bug#47768 pthread_cond_timedwait() is broken on windows · dfed28e7
      Kristofer Pettersson authored
      The pthread_cond_wait implementations for windows might
      dead lock in some rare circumstances.
      
      1) One thread (I) enter a timed wait and at a point in
         time ends up after mutex unlock and before
         WaitForMultipleObjects(...)
      2) Another thread (II) enters pthread_cond_broadcast.
         Grabs the mutex and discovers one waiter. It set
         the broadcast event and closes the broadcast gate
         then unlocks the mutex.
      3) A third thread (III) issues a pthread_cond_signal.
         It grabs the mutex, discovers one waiter, sets the
         signal event then unlock the mutex.
      4) The first threads (I) enters WaitForMultipleObjects
         and finds out that the signal object is in a
         signalled state and exits the wait.
      5) Thread (I) grabs the mutex and checks result status.
         The number of waiters is decreased and becomes equal
         to 0. The event returned was a signal event so the
         broadcast gate isn't opened. The mutex is released.
      6) Thread (II) issues a new broadcast. The mutex is
         acquired but the number of waiters are 0 hence
         the broadcast gate remains closed.
      7) Thread (I) enters the wait again but is blocked by
         the broadcast gate.
      
            This fix resolves the above issue by always resetting
            broadcast gate when there are no more waiters in th queue.
      dfed28e7
    • Georgi Kodinov's avatar
      version update · bf1b7b7d
      Georgi Kodinov authored
      bf1b7b7d
  13. 05 Oct, 2009 1 commit
  14. 04 Oct, 2009 1 commit
  15. 02 Oct, 2009 1 commit
  16. 30 Sep, 2009 9 commits
    • Davi Arnaut's avatar
      Post-merge cleanup: Reorganize code for better comprehensibility. · 1442ef0f
      Davi Arnaut authored
                          Removes the need of a hack (the jump to label).
      1442ef0f
    • Davi Arnaut's avatar
      e1e038ab
    • Davi Arnaut's avatar
      Bug#47525: MySQL crashed (Federated) · d941a1f3
      Davi Arnaut authored
      On Mac OS X or Windows, sending a SIGHUP to the server or a
      asynchronous flush (triggered by flush_time), would cause the
      server to crash.
      
      The problem was that a hook used to detach client API handles
      wasn't prepared to handle cases where the thread does not have
      a associated session.
      
      The solution is to verify whether the thread has a associated
      session before trying to detach a handle.
      d941a1f3
    • Jonathan Perkin's avatar
      bug#27693: Windows compilation from bk fails using WITH_BERKELEY_STORAGE_ENGINE · 706241d6
      Jonathan Perkin authored
      Make configure.js bail with an error if trying to build bdb from a bzr
      tree.
      706241d6
    • Kristofer Pettersson's avatar
      Bug#34895 'show procedure status' or 'show function status' + · f7ebdaef
      Kristofer Pettersson authored
                'flush tables' crashes
      
      The server crashes when 'show procedure status' and 'flush tables' are
      run concurrently.
      
      This is caused by the way mysql.proc table is added twice to the list
      of table to lock although the requirements on the current locking API
      assumes differently.
      
      No test case is submitted because of the nature of the crash which is 
      currently difficult to reproduce in a deterministic way.
      
      This is a backport from 5.1
      f7ebdaef
    • MySQL Build Team's avatar
      Backport into build-200909301147-5.0.84sp1 · 9b28e814
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2802.1.1
      > tags: mysql-5.0.86
      > revision-id: hery.ramilison@sun.com-20090909185217-mooeczu391ztp2fz
      > parent: joro@sun.com-20090902123318-8qe40pr91xmui5ue
      > committer: hery <hery.ramilison@sun.com>
      > branch nick: mysql-5.0.86-release
      > timestamp: Wed 2009-09-09 20:52:17 +0200
      > message:
      >   change c++ comment to c comment
      9b28e814
    • MySQL Build Team's avatar
      Backport into build-200909301147-5.0.84sp1 · 97f1600d
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2796
      > revision-id: sergey.glukhov@sun.com-20090827102219-sgjz0v5t1rfccs14
      > parent: joro@sun.com-20090824122803-1d5jlaysjc7a7j6q
      > committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
      > branch nick: mysql-5.0-bugteam
      > timestamp: Thu 2009-08-27 15:22:19 +0500
      > message:
      >   Bug#46184 Crash, SELECT ... FROM derived table procedure analyze
      >   The crash happens because select_union object is used as result set
      >   for queries which have derived tables.
      >   select_union use temporary table as data storage and if
      >   fields count exceeds 10(count of values for procedure ANALYSE())
      >   then we get a crash on fill_record() function.
      97f1600d
    • MySQL Build Team's avatar
      Backport into build-200909301147-5.0.84sp1 · 9d827fef
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2791.2.3
      > revision-id: joro@sun.com-20090827114042-h55n7qp9990bl6ge
      > parent: anurag.shekhar@sun.com-20090831073231-e55y1hsck6n08ux8
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B46749-5.0-bugteam
      > timestamp: Thu 2009-08-27 14:40:42 +0300
      > message:
      >   Bug #46749: Segfault in add_key_fields() with outer subquery level 
      >     field references
      >   
      >   This error requires a combination of factors : 
      >   1. An "impossible where" in the outermost SELECT
      >   2. An aggregate in the outermost SELECT
      >   3. A correlated subquery with a WHERE clause that includes an outer 
      >   field reference as a top level WHERE sargable predicate
      >   
      >   When JOIN::optimize detects an "impossible WHERE" it will bail out
      >   without doing the rest of the work and initializations. It will not
      >   call make_join_statistics() as well.  And make_join_statistics fills 
      >   in various structures for each table referenced.
      >   When processing the result of the "impossible WHERE" the query must
      >   send a single row of data if there are aggregate functions in it.
      >   In this case the server marks all the aggregates as having received 
      >   no rows and calls the relevant Item::val_xxx() method on the SELECT
      >   list. However if this SELECT list happens to contain a correlated 
      >   subquery this subquery is evaluated in a normal evaluation mode.
      >   And if this correlated subquery has a reference to a field from the 
      >   outermost "impossible where" SELECT the add_key_fields will mistakenly
      >   consider the outer field reference as a "local" field reference when 
      >   looking for sargable predicates.
      >   But since the SELECT where the outer field reference refers to is not
      >   completely initialized due to the "impossible WHERE" in this level
      >   we'll get a NULL pointer reference.
      >   Fixed by making a better condition for discovering if a field is "local"
      >   to the SELECT level being processed. 
      >   It's not enough to look for OUTER_REF_TABLE_BIT in this case since 
      >   for outer references to constant tables the Item_field::used_tables() 
      >   will return 0 regardless of whether the field reference is from the 
      >   local SELECT or not.
      9d827fef
    • sunanda.menon@sun.com's avatar
      c18746a4