1. 05 Nov, 2009 6 commits
  2. 03 Nov, 2009 2 commits
    • Kristofer Pettersson's avatar
    • Vladislav Vaintroub's avatar
      Bug #47423 mtr connects to wrong database · 9b1284db
      Vladislav Vaintroub authored
      The reason for the bug is that mysqtest as well as other client tools
      running in test suite (mysqlbinlog, mysqldump) will first try to connect 
      whatever database has created shared memory with default base name 
      "MySQL" and use this. (Same effect could be seen on Unix if mtr would
      not care to calculate "port" and "socket" parameter).
            
      The fix ensures that all client tools and  running in mtr use unique  
      per-database shared memory base parameters, so there is no possibility
      to clash with already installed one. We use socket name for shared memory 
      base (it's known to be unique). This shared-memory-base is written to the
      MTR config file to the [client] and [mysqld] sections. Fix made also made 
      sure all client tools understand and correctly handle --shared-memory-base.
      Prior to this patch  it was not the case for  mysqltest, mysqlbinlog and 
      mysql_client_test.
            
      All new connections done from mtr scripts via connect() will by default 
      set shared-memory-base. And finally, there is a possibility to force 
      shared memory or pipe connection and overwrite shared memory/pipe base name
      from within mtr scripts via optional PIPE or SHM modifier. This functionality
      was manually backported from 6.0
      (original patch  http://lists.mysql.com/commits/74749)
      9b1284db
  3. 02 Nov, 2009 1 commit
    • Vladislav Vaintroub's avatar
      Bug#47571: idle named pipe connection is unkillable · 57d5db91
      Vladislav Vaintroub authored
      Bug#31621: Windows server hanging during shutdown using named pipes 
                 and idle connection
                  
      Problem: when idle pipe connection is forcefully closed with KILL
      statement or when the server goes down, thread that is closing connection
      would hang infinitely in CloseHandle(). The reason for the hang is that 
      named pipe operations are performed synchronously. In this mode all IOs
      on pipe are serialized, that is CloseHandle() will not abort ReadFile() 
      in another thread, but wait for ReadFile() to complete.
                  
      The fix implements asynchrnous mode for named pipes, where operation of file
      are not synchronized. Read/Write operation would fire an async IO and wait for
      either IO completion or timeout.
                  
      Note, that with this patch timeouts are properly handled for named pipes.
            
      Post-review: Win32 timeout code has been fixed for named pipes and shared
      memory. We do not store pointer to NET in vio structure, only the read and 
      write timeouts.
      
      
      include/violite.h:
        Add pipe_overlapped to Vio structure for async IO for named pipes.
      sql-common/client.c:
        Use asynchronous pipe IO.
      sql/mysqld.cc:
        Use asynchronous pipe IO.
      vio/vio.c:
        -Refactor timeouts for win32 protocols: shared memory and named pipes.
        Store read/write timeout in VIO structure, instead of storing pointer
        to NET. New function vio_win32_timeout called indirectly via 
        vio_timeout changes these values.
      vio/vio_priv.h:
        Remove vio_ignore_timeout.
        Add vio_win32_timeout to be used for named pipes and shared memory.
      vio/viosocket.c:
        Use async IO for named pipes.
        After issuing IO, wait for either IO completion, pipe_close_event
        or timeout.
                
        Refactor timeouts for named pipe and shared memory.
      57d5db91
  4. 31 Oct, 2009 1 commit
  5. 27 Oct, 2009 13 commits
    • Tatiana A. Nurnberg's avatar
      auto-merge · 4e027f2e
      Tatiana A. Nurnberg authored
      4e027f2e
    • Georgi Kodinov's avatar
      merge · 05d323fa
      Georgi Kodinov authored
      05d323fa
    • Tatiana A. Nurnberg's avatar
      Bug#46586: When using the plugin interface the type "set" for options caused a crash. · 7cfc590e
      Tatiana A. Nurnberg authored
      "What do you mean, there's a bug? There isn't even code!"
      
      There was some token code for plug-in variables of the SET type,
      but clearly this never worked, or was subject to massive bit rot
      since. Bug-fixes ... fail-safes ... tests -- fais au mieux, mon chou!
      
      mysys/my_getopt.c:
        SETs set-up should set up a default value, but no min/max bounding.
      mysys/typelib.c:
        fail-safe requested by serg: don't try to skip separator when we're
        already at end of string.
      sql/sql_plugin.cc:
        check_func_set:
        Initialize error_len as find_set() will only update it on error,
        and we're using the value to see whether an error has occurred (!= 0),
        so we'd better not have a random val in there.
        
        value_ptr:
        There's no guarantee we're handed string lengths, so play it safe!
        Use prepared string lengths where possible for minimum speed gain,
        otherwise determine on the fly!
      7cfc590e
    • Georgi Kodinov's avatar
      merge from 4.1 · 43c33434
      Georgi Kodinov authored
      43c33434
    • Sergey Glukhov's avatar
      null merge · 7cfe3c15
      Sergey Glukhov authored
      7cfe3c15
    • Sergey Glukhov's avatar
      automerge · 1ff93333
      Sergey Glukhov authored
      1ff93333
    • Sergey Glukhov's avatar
      automerge · 66be8eb4
      Sergey Glukhov authored
      66be8eb4
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 617d743e
      Sergey Glukhov authored
      617d743e
    • Alexander Nozdrin's avatar
      170adfa3
    • Tatiana A. Nurnberg's avatar
      auto-merge · 2b80974c
      Tatiana A. Nurnberg authored
      2b80974c
    • Sergey Vojtovich's avatar
      0d94e3ad
    • Sergey Vojtovich's avatar
      An addition to fix for · 5099429d
      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.
      
      sql/sql_acl.cc:
        Fixed build failure on Windows. Added missing cast.
      5099429d
    • Sergey Glukhov's avatar
      Bug#41049 does syntax "grant" case insensitive? · ea2fe6bc
      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).
      
      
      mysql-test/include/have_case_insensitive_fs.inc:
        test case
      mysql-test/r/case_insensitive_fs.require:
        test case
      mysql-test/r/grant_lowercase_fs.result:
        test result
      mysql-test/r/lowercase_fs_off.result:
        test result
      mysql-test/r/ps_grant.result:
        test result
      mysql-test/r/system_mysql_db.result:
        changed Routine_name field collation to case insensitive
      mysql-test/t/grant_lowercase_fs.test:
        test case
      mysql-test/t/lowercase_fs_off.test:
        test case
      scripts/mysql_system_tables.sql:
        changed Routine_name field collation to case insensitive
      scripts/mysql_system_tables_fix.sql:
        changed Routine_name field collation to case insensitive
      sql/sql_acl.cc:
        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).
      ea2fe6bc
  6. 26 Oct, 2009 1 commit
  7. 22 Oct, 2009 8 commits
  8. 21 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #47780: crash when comparing GIS items from subquery · 98bf634a
      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).
      98bf634a
  9. 23 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#48258: Assertion failed when using a spatial index · 21e9dc9f
      Ramil Kalimullin authored
      Problem: involving a spatial index for "non-spatial" queries
      (that don't containt MBRXXX() functions) may lead to failed assert.
      
      Fix: don't use spatial indexes in such cases.
      
      
      mysql-test/r/gis-rtree.result:
        Fix for bug#48258: Assertion failed when using a spatial index
          - test result.
      mysql-test/t/gis-rtree.test:
        Fix for bug#48258: Assertion failed when using a spatial index
          - test case.
      sql/opt_range.cc:
        Fix for bug#48258: Assertion failed when using a spatial index
          - allow only spatial functions (MBRXXX) for itMBR keyparts.
      21e9dc9f
  10. 21 Oct, 2009 2 commits
    • Ramil Kalimullin's avatar
      Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, · 5e3f89fd
      Ramil Kalimullin authored
      line 138 when forcing a spatial index
      
      Problem: "Spatial indexes can be involved in the search 
      for queries that use a function such as MBRContains() 
      or MBRWithin() in the WHERE clause".
      Using spatial indexes for JOINs with =, <=> etc.
      predicates is incorrect.
      
      Fix: disable spatial indexes for such queries.
      
      
      mysql-test/r/select.result:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test result.
      mysql-test/t/select.test:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test case.
      sql/sql_select.cc:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - disable spatial indexes for queries which use 
        non-spatial conditions (e.g. NATURAL JOINs).
      5e3f89fd
    • Tatiana A. Nurnberg's avatar
      auto-merge · 5b5fc532
      Tatiana A. Nurnberg authored
      5b5fc532
  11. 20 Oct, 2009 4 commits