1. 25 Nov, 2016 1 commit
    • Alexander Barkov's avatar
      MDEV-11348 LOAD DATA LOCAL INFILE crashes the server on loading a backslash... · 099ce1dd
      Alexander Barkov authored
      MDEV-11348 LOAD DATA LOCAL INFILE crashes the server on loading a backslash followed by a multi-byte character
      
      The crash happened when if my_error() was called for any reasons during loading
      (e.g. a bad multi-byte sequence or a bad GEOMETRY value was found).
      The server sent both error and progress packets, so the client disconnected.
      The server then crashed on a assert about a wrong packet order in Debug build.
      The server also tried to read from a closed socket when calling
      READ_INFO::skip_data_till_eof().
      
      As the crash happened only with "mysql" running in interactive mode,
      no tests are possible. The problem was not reproducible with
      "mysqltest" or "mysql" in batch mode.
      099ce1dd
  2. 17 Nov, 2016 2 commits
  3. 16 Nov, 2016 1 commit
    • Kristian Nielsen's avatar
      Fix incorrect reading of events from relaylog in parallel replication. · 390f2a01
      Kristian Nielsen authored
      The SQL thread keeps track of the position in the current relay log from
      which to read the next event. This position is not normally used, but a
      certain interaction with the IO thread can cause the SQL thread to re-open
      the relay log and seek to the stored position.
      
      In parallel replication, there were a couple of places where the position
      was not updated. This created a race where a re-open of the relay log could
      seek to the wrong position and start re-reading and processing events
      already handled once, causing various kinds of problems.
      
      Fix this by moving the position update into a single place in
      apply_event_and_update_pos(), which should ensure that the position is
      always updated in the parallel replication case.
      
      This problem was found from the testcase of MDEV-10863, but it is logically
      a separate problem.
      390f2a01
  4. 15 Nov, 2016 2 commits
  5. 10 Nov, 2016 1 commit
    • Alexander Barkov's avatar
      A join patch for MDEV-10780 and MDEV-11265 · 1d9b043a
      Alexander Barkov authored
      MDEV-10780 Server crashes in in create_tmp_table
      MDEV-11265 Access defied when CREATE VIIEW v1 AS SELECT DEFAULT(column) FROM t1
      
      Item_default_value and Item_insert_value erroneously derive from Item_field
      but forgot to override some methods that apply only to true fields,
      so the server code mixes Item_{default|insert}_value instances with real
      table fields (i.e. true Item_field) in some cases.
      Overriding a few methods to avoid this.
      
      TODO: we should eventually derive Item_default_value (and Item_insert_value)
      directly from Item, as they don't really need the entire Item_field,
      Item_ident and Item_result_field functionality.
      Only the member "Field *field" related functionality is actually needed,
      like val_xxx(), is_null(), get_geometry_type(), charset_for_protocol(), etc.
      1d9b043a
  6. 04 Nov, 2016 1 commit
    • Kristian Nielsen's avatar
      MDEV-10863: parallel replication tries to continue from wrong position · 717f2128
      Kristian Nielsen authored
      This occured when the SQL thread (but not the IO thread) stops while
      GTID and parallel replication are used with multiple domain ids in the
      GTID position, and is restarted.
      
      In this case, the SQL needs to start some way back in the relay log,
      applying or skipping events within each replication domain as
      appropriate.
      
      The SQL threads starts at the beginning of an old relay log file, and
      this position may be in the middle of an event group. The bug was that
      such partial event group could be re-applied, causing replication
      corruption.
      
      This patch fixes the issue, by making sure to skip any initial events
      that were part of an earlier (already applied) event group.
      717f2128
  7. 01 Nov, 2016 1 commit
  8. 31 Oct, 2016 1 commit
  9. 28 Oct, 2016 2 commits
  10. 27 Oct, 2016 4 commits
  11. 26 Oct, 2016 9 commits
  12. 25 Oct, 2016 12 commits
  13. 23 Oct, 2016 1 commit
  14. 22 Oct, 2016 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-11104 Fix client to correctly retrieve current user name on Windows · fb38d264
      Vladislav Vaintroub authored
      Prior to this patch name of the user was  read from environment variable
      USER, with a fallback to 'ODBC', if the environment variable is not set.
      
      The name of the env.variable is incorrect (USERNAME usually contains current
      user's name,  but not USER), which made client to  always determine
      current user as 'ODBC'.
      
      The fix is to use GetUserName() instead.
      fb38d264
  15. 21 Oct, 2016 1 commit