1. 28 Feb, 2017 1 commit
    • Sujatha Sivakumar's avatar
      Bug#24901077: RESET SLAVE ALL DOES NOT ALWAYS RESET SLAVE · e619295e
      Sujatha Sivakumar authored
      Description:
      ============
      If you have a relay log index file that has ended up with
      some relay log files that do not exists, then RESET SLAVE
      ALL is not enough to get back to a clean state.
      
      Analysis:
      =========
      In the bug scenario slave server is in stopped state and
      some of the relay logs got deleted but the relay log index
      file is not updated.
      
      During slave server restart replication initialization fails
      as some of the required relay logs are missing. User
      executes RESET SLAVE/RESET SLAVE ALL command to start a
      clean slave. As per the documentation RESET SLAVE command
      clears the master info and relay log info repositories,
      deletes all the relay log files, and starts a new relay log
      file. But in a scenario where the slave server's
      Relay_log_info object is not initialized slave will not
      purge the existing relay logs. Hence the index file still
      remains in a bad state. Users will not be able to start
      the slave unless these files are cleared.
      
      Fix:
      ===
      RESET SLAVE/RESET SLAVE ALL commands should do the cleanup
      even in a scenario where Relay_log_info object
      initialization failed.
      
      Backported a flag named 'error_on_rli_init_info' which is
      required to identify slave's Relay_log_info object
      initialization failure. This flag exists in MySQL-5.6
      onwards as part of BUG#14021292 fix.
      
      During RESET SLAVE/RESET SLAVE ALL execution this flag
      indicates the Relay_log_info initialization failure.
      In such a case open the relay log index/relay log files
      and do the required clean up.
      e619295e
  2. 27 Feb, 2017 2 commits
  3. 24 Feb, 2017 1 commit
    • Arun Kuruvila's avatar
      Bug#25608828: I_MAIN.VARIABLES-BUG21503595 FAILS · 18b3aa11
      Arun Kuruvila authored
                    SPORADICALLY ON PB2-5.5 FOR LINUX-VALGRIND
      
      Description: Sporadic failure of variables-bug21503595 test
      on pb2-5.5 for linux-valgrind platform.
      
      Fix: This is a issue related to libc and not related to
      MySQL code. During dlclose few blocks of memory left
      unfreed. This is a known issue in libc and needs to be
      suppressed.
      
      Fix: Added a valgrind suppression.
      18b3aa11
  4. 23 Feb, 2017 2 commits
    • Dyre Tjeldvoll's avatar
      Bug#25514146: DB_NAME IS IGNORED WHEN CREATING TABLE WITH DATA DIRECTORY · 7849a27c
      Dyre Tjeldvoll authored
      Problem: CREATE TABLE using a fully qualified name with INDEX DIR/DATA DIR
      option reports an error when the current database is not SET.
      
      check_access() was incorrectly called with NULL as the database
      argument in a situation where the database name was not needed for
      the particular privilege being checked. This will cause the current
      database to be used, or an error to be reported if there is no current
      database.
      
      Fix: Call check_access() with any_db as the database argument in this situation.
      7849a27c
    • Ajo Robert's avatar
      Bug#23195404 EXCESSIVE MEMORY CAN BE USED BY THE QUOTE() · b21a0212
      Ajo Robert authored
      			  STRING FUNCTION
      
      Fix:
      =======
      Added code in QUOTE string function to honor max_allowed_packet.
      b21a0212
  5. 16 Feb, 2017 1 commit
  6. 14 Feb, 2017 1 commit
  7. 13 Feb, 2017 1 commit
    • Terje Rosten's avatar
      Bug#25144379 MYSQLD PROCESS DOES NOT INCLUDE FULL PATH WHEN STARTING MYSQL SERVER · b7f33d22
      Terje Rosten authored
      Fix of Bug#25088048 caused paths to be relative, not absolute, this
      proved to be problematic.
      
      Fix is to still ignore current working directory, however switch to
      using full path of basedir, which is set to parent directory of bin/
      directory where mysqld_safe is located.
      
      References to legacy tool mysql_print_defaults are removed, only
      my_print_defaults is used these days.
      
      This will also fix:
        Bug#11745176 (11192) MYSQLD_SAFE ONLY EVALUATES --DEFAULTS-FILE OPTION WHEN IT IS THE FIRST OP
        Bug#23013510 (80866) MYSQLD_SAFE SHOULD NOT SEARCH $MY_BASEDIR_VERSION/VAR AS DATADIR
        Bug#25244898 (84173) MYSQLD_SAFE --NO-DEFAULTS & SILENTLY DOES NOT WORK ANY MORE
        Bug#25261472 (84219) INITSCRIPT ERRORS WHEN LAUCHING MYSQLD_SAFE IN NON DEFAULT BASEDIR
        Bug#25319392 (84263) MYSQL.SERVER (MYSQL SERVER STARTUP SCRIPT) CAN NOT WORK,AND EXPORT SOME ERROR.
        Bug#25319457         MYSQLD_SAFE MIGHT FAIL IF $DATADIR HAS TRAILING /
        Bug#25341981         MYSQLD_SAFE ASSUMES INCORRECT BASEDIR WHEN EXECUTED WITH ABSOLUTE PATH
        Bug#25356221 (84427) MYSQLD_SAFE FAILS TO START WHEN USING A FIFO FOR LOG-ERROR (REGRESSION)
        Bug#25365194 (84447) MYSQLD_SAFE DOESN'T CHECK EXISTENCE OF GIVEN BASEDIR PARAMETER
        Bug#25377815         ERRORS WHILE STARTING MYSQLD_SAFE WITH SYM LINK ENABLED
      b7f33d22
  8. 31 Jan, 2017 1 commit
    • Shishir Jaiswal's avatar
      Bug#24619033 - UNABLE TO START MYSQLD DUE TO CHANGES IN · df6e0160
      Shishir Jaiswal authored
                     MYSQLD_SAFE
      
      DESCRIPTION
      ===========
      Starting a mysql server by running init script:
      /etc/init.d/mysqld start
      
      is failing. This is happening after the changes done in
      script 'mysqld_safe' as a patch to Bug#24464380.
      
      ANALYSIS
      ========
      Say customer's /etc/my.cnf has following content:
      
      [mysqld_safe]
      .
      .
      ledir  = /mysqld_ledir
      mysqld = mysqld_wrapper
      
      Patch to Bug#24464380 prohibits using "mysqld" (and few
      other variables) in config file due to privilege reasons.
      Since mysqld init scripts internally calls 'mysqld_safe'
      script, the existing configuration has started failing.
      
      FIX
      ===
      In the init script, we now pass MYSQLD_OPTS as the first
      argument (expected to be read from /etc/sysconfig/mysqld)
      to mysqld_safe command. This new variable can have all the
      mysqld_safe's special options as a string containing command
      line arguments. For example:
      
      MYSQLD_OPTS=" --ledir=/mysqld_ledir --mysqld=my_wrapper "
      
      NOTE TO THE DOCUMENTATION TEAM
      ==============================
      As mentioned above, the prohibited variables have to be
      moved from /etc/my.cnf to /etc/sysconfig/mysqld as a string
      containing command-line arguments in the form of variable
      MYSQLD_OPTS. We can pass mysqld options as well in this new
      variable which would be further passed to mysqld process.
      df6e0160
  9. 30 Jan, 2017 1 commit
    • Thayumanavar S's avatar
      WL#10287 - Backport WL#7195 to MySQL - 5.5 · 35809da2
      Thayumanavar S authored
      This is backport of WL#7195 to MySQL-5.5. In 5.5, we
      offload connection authentication from the acceptor
      thread to tp worker threads.
      
      Connection authentication happens in the acceptor thread that
      accepts the connection for thread pool plugin. Connection authentication
      involves exchanging packets with client and disk I/O
      which is time consuming. This can cause other client
      connections to starve and wait in the queue possibly increasing the
      connect latency and decreasing throughput. In the worst case, some
      connections could be dropped. n addition, SSL handshakes are quite
      expensive and can stall connections in the accept queue.
      
      This patch offloads connection authentication when thread pool
      plugin is used for client connection. Each thread group
      shall have a queue of connection_context objects, which represents
      new connections that need to be processed by thread group threads.
      The connection context is composed of THD object & list pointers
      for intrusive queue implementation. Whenever a new connection
      arrives, connection context object is created and added to the
      queue. A new connect handler thread is created or woken up to handle
      the authentication task. The worker thread loop is modified to
      process connection events on connect handler threads in addition to
      checking for query processing events. The initial number of connect
      handler threads is one per thread group and it is restricted to
      a maximum of 4 threads per thread group.
      35809da2
  10. 17 Jan, 2017 2 commits
  11. 06 Jan, 2017 2 commits
  12. 03 Jan, 2017 1 commit
  13. 22 Dec, 2016 1 commit
    • Shishir Jaiswal's avatar
      Bug#11751149 - TRYING TO START MYSQL WHILE ANOTHER INSTANCE · e00810b9
      Shishir Jaiswal authored
                     IS STARTING: CONFUSING ERROR
      
      DESCRIPTION
      ===========
      When mysql server processes transactions but has not yet
      committed and shuts down abnormally (due to crash, external
      killing etc.), a recovery is due from Storage engine side
      which takes place the next time mysql server (either
      through mysqld or mysqld_safe) is run.
      
      While the 1st server is in mid of recovery, if another
      instance of mysqld_safe is made to run, it may result into
      2nd instance killing the 1st one after a moment.
      
      ANALYSIS
      ========
      In the "while true" loop, we've a check (which is done
      after the server stops) for the existence of pid file to
      enquire if it was a normal shutdown or not. If the file is
      absent, it means that the graceful exit of server had
      removed this file.
      
      However if the file is present, the scripts makes a plain
      assumption that this file is leftover of the "current"
      server. It misses to consider that it could be a valid pid
      file belonging to another running mysql server.
      
      We need to add more checks in the latter case. The script
      should extract the PID from this existing file and check if
      its running or not. If yes, it means an older instance of
      mysql server is running and hence the script should abort.
      
      FIX
      ===
      Checking the status of process (alive or not) by adding a
      @CHECK_PID@ in such a case. Aborting if its alive. Detailed
      logic is as follows:
      
      - The mysqld_safe script would quit at start only as soon
      as it finds that there is an active PID i.e. a mysql server
      is already running.
      - The PID file creation takes place after InnoDb recovery,
      which means in rare case (when PID file isn't created yet)
      it may happen that more than 1 server can come up but even
      in that case others will have to wait till the 1st server
      has released the acquired InnoDb lock. In this case all
      these servers will either TIMEOUT waiting for InnoDb lock
      or after this they would find that the 1st server is
      already running (by reading $pid_file) and would abort.
      - Our core fix is that we now check the status of mysql
      server process (alive or not) after the server stops
      running within the loop of "run -> shutdown/kill/abort ->
      run ... ", so that only the script who owns the mysql
      server would be able to bring it down if required.
      
      NOTE
      ====
      Removed the deletion of pid file and socket file from entry
      of the loop, as it may result in 2nd instance deleting
      these files created by 1st instance in RACE condition.
      Compensated this by deleting these files at end of the loop
      
      Reverted the changes made in patch to Bug#16776528. So
      after this patch is pushed, the concept of mysqld_safe.pid
      would go altogether. This was required as the script was
      deleting other instance's mysqld_safe.pid allowing multiple
      mysqld_safe instances to run in parallel. This patch would
      fix Bug#16776528 as well as the resources would be guarded
      anyway by InnoDb lock + our planned 5.7 patch.
      e00810b9
  14. 19 Dec, 2016 1 commit
  15. 13 Dec, 2016 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #24595937: INCORRECT BEHAVIOR WHEN LOADING DATA TO VIEW · 30a59a8d
      Sreeharsha Ramanavarapu authored
      Issue:
      ------
      While using the LOAD statement to insert data into an
      updateable view, the check to verify whether a column
      is actually updatable is missing.
      
      Solution for 5.5 and 5.6:
      -------------------------
      For a view whose column-list in specified in the LOAD
      command, this check is not performed. This fix adds the
      check.
      
      This is a partial backport of Bug#21097485.
      
      Solution for 5.7 and trunk:
      ---------------------------
      For a view whose column-list is specified in the LOAD
      command, this check is already performed. This fix adds the
      same check when no column-list is specified.
      30a59a8d
  16. 12 Dec, 2016 1 commit
  17. 06 Dec, 2016 1 commit
  18. 05 Dec, 2016 3 commits
    • Georgi Kodinov's avatar
      Bug #25111907: XML TEST FAILS WITH UNDEFINED BEHAVIOR · dafbdc78
      Georgi Kodinov authored
      The XML parser position stack for each level is with a fixed depth.
      So a bounds check was done to ensure that this depth is not exceeded.
      But it was off by one (i.e. the size of the array was a valid index).
      Fixed by decreasing the allowable depth by one to match the maximum
      number of elements in the position stack.
      dafbdc78
    • Terje Rosten's avatar
      Bug#22240513 REMOVE GITIGNORE / BZRIGNORE FROM OFFICIAL RELEASE · 67226995
      Terje Rosten authored
      Add .gitattributes to let git archive ignore .gitignore.
      67226995
    • Pavan Naik's avatar
      BUG#25147154 : MTR TRIES TO COPY CONTENTS FROM /TMP/DATA · 6786caed
      Pavan Naik authored
      Description :
      =============
      When a MTR test run is started, it initializes the server and creates
      the datadir under '$MYSQL_TEST_DIR/var'('/tmp/var' or '/dev/shm/var'
      if --mem option is used) location and then copies it to the datadir
      location of server(s).
      
      If $parallel == 1, datadir location of the server is
      '$MYSQL_TEST_DIR/var/data'. If $parallel > 1, datadir location of any
      server is '$MYSQL_TEST_DIR/var/<thread_num>/data'.
      
      This is the reason MTR searches for the initialized datadir in 2
      locations('$opt_vardir' and '$opt_vardir/..') from the current vardir
      location..
      
      But this can cause few problems. If a directory with the name 'data'
      already exists under '$MYSQL_TEST_DIR' and if the MTR run is started
      with parallel value 1, then
      
      1. copytree($install_db, '$opt_vardir/..') command will fail if the
      user doesn't have the access permission to '$MYSQL_TEST_DIR/data'
      directory.
      2. Unnecessary contents from '$MYSQL_TEST_DIR/data' directory will be
      copied to server datadir location and this might affect the server
      startup.
      
      Fix :
      =====
      Depending on the $parallel value decide whether the path for the
      initialize datadir is "$opt_vardir"(i.e $parallel = 1) or
      "$opt_vardir/.."(i.e $parallel > 1).
      Reviewed-by: default avatarDeepa Dixit <deepa.dixit@oracle.com>
      Reviewed-by: default avatarSrikanth B R <srikanth.b.r@oracle.com>
      RB: 14773
      6786caed
  19. 04 Dec, 2016 1 commit
  20. 29 Nov, 2016 2 commits
    • Shishir Jaiswal's avatar
      Bug#24449076 - INTEGER OVERFLOW IN FUNCTION DOINSERT · 52b0c814
      Shishir Jaiswal authored
      DESCRIPTION
      ===========
      Performing a pattern match of a Regex resulting into a very
      large string, leads to crash due to integer wraparound.
      
      ANALYSIS
      ========
      doinsert() - The length calculated here (to copy the
      number of bytes) comes out to be too large to be stored in
      the "int" variable 'length'. We need to ensure that the
      variable can accommodate large lengths.
      
      FIX
      ===
      'length' in doinsert() is now defined as of type "size_t"
      instead of "int"
      52b0c814
    • Shishir Jaiswal's avatar
      Bug#24449090 - BUFFER OVERFLOW IN FUNCTION DUPL · 8f297058
      Shishir Jaiswal authored
      DESCRIPTION
      ===========
      Performing a pattern match of a Regex resulting into a very
      large string, leads to crash due to failed realloc().
      
      ANALYSIS
      ========
      dupl() calls enlarge(). It in turn calls realloc() for
      pointer p->strip. This eventually fails due to OOM.
      However we are still using the same pointer in memcpy()
      causing a SEGFAULT!
      
      FIX
      ===
      1) In dupl(), checking for error code (which would be set
      if realloc fails) immediately after call to enlarge().
      Returning now with this error code.
      
      2) Handling the same in the caller functions.
      8f297058
  21. 28 Nov, 2016 4 commits
  22. 26 Nov, 2016 2 commits
  23. 25 Nov, 2016 3 commits
  24. 24 Nov, 2016 2 commits
  25. 16 Nov, 2016 1 commit
    • Terje Rosten's avatar
      Bug#25088048 ADDITIONAL ISSUES IN MYSQLD_SAFE · cdd57aa7
      Terje Rosten authored
      Don't read --ledir option from config file.
      Ignore current working for finding location of mysqld
      Remove use of chown/chmod in scripts.
      Be helpful only when basedir is /var/log or /var/lib.
      Removed unused systemd files for SLES.
      Set explicit basedir in scripts.
      cdd57aa7
  26. 10 Nov, 2016 1 commit
    • Karthik Kamath's avatar
      BUG#24437124: POSSIBLE BUFFER OVERFLOW ON CREATE TABLE · a63185e8
      Karthik Kamath authored
      ANALYSIS:
      =========
      'CREATE TABLE' query with a large value for 'CONNECTION'
      string reports an incorrect error.
      
      The length of connection string is stored in .frm in two
      bytes (max value= 65535). When the string length exceeds
      the max value, the length is truncated to fit the two
      bytes limit. Further processing leads to reading only a
      part of the string as the length stored is incorrect. The
      remaining part of the string is treated as engine type and
      hence results in an error.
      
      FIX:
      ====
      We are now restricting the connection string length to 1024.
      An appropriate error is reported if the length crosses this
      limit.
      
      NOTE:
      =====
      The 'PASSWORD' table option is documented as unused and
      processed within a dead code. Hence it will not cause
      similar issue with large strings.
      a63185e8