1. 10 Jun, 2011 8 commits
    • Daniel Fischer's avatar
      96b6dc6d
    • Jon Olav Hauglid's avatar
      Bug#12584161 - 43861: MAIN.QUERY_CACHE_28249 FAILS SPORADICALLY · cc4530f9
      Jon Olav Hauglid authored
      This test case was failing on 5.5 and trunk for two reasons.
      1) It waited for the "Waiting for table level lock" process
         state while this state was renamed "Waiting for table
         metadata lock" with the introduction of MDL in 5.5.
      2) SET GLOBAL query_cache_size= 100000; gave a warning since
         query_cache_size is supposed to be multiples of 1024.
      
      This patch fixes these two issues and re-enables the test case.
      cc4530f9
    • Jorgen Loland's avatar
      local merge · 9506c818
      Jorgen Loland authored
      9506c818
    • Sunanda Menon's avatar
      increased the version number to .15 · 7e39ef17
      Sunanda Menon authored
      7e39ef17
    • Jorgen Loland's avatar
      BUG#12561818 - RERUN OF STORED FUNCTION GIVES ERROR 1172: · fb110da7
      Jorgen Loland authored
                     RESULT CONSISTED OF MORE THAN ONE ROW
      
      MySQL converts incorrect DATEs and DATETIMEs to '0000-00-00' on
      insertion by default. This means that this sequence is possible:
      
      CREATE TABLE t1(date_notnull DATE NOT NULL);
      INSERT INTO t1 values (NULL);
      SELECT * FROM t1;
      0000-00-00
      
      At the same time, ODBC drivers do not (or at least did not in the
      90's) understand the DATE and DATETIME value '0000-00-00'. Thus,
      to be able to query for the value 0000-00-00 it was decided in
      MySQL 4.x (or maybe even before that) that for the special case
      of DATE/DATETIME NOT NULL columns, the query "SELECT ... WHERE
      date_notnull IS NULL" should return rows with date_notnull ==
      '0000-00-00'. This is documented misbehavior that we do not want
      to change.
      
      The hack used to make MySQL return these rows is to convert 
      "date_notnull IS NULL" to "date_notnull = 0". This is, however,
      only done if the table date_notnull belongs to is not an inner
      table of an outer join. The rationale for this seems to be that
      if there is no join match for the row in the outer table,
      null-complemented rows would otherwise not be returned because
      the null-complemented DATE value is actually NULL. On the other
      hand, this means that the "return rows with 0000-00-00 when the
      query asks for IS NULL"-hack is not in effect for outer joins.
      
      In this bug, we have a LEFT JOIN that does not misbehave like 
      the documentation says it should. The fix is to rewrite
      
      "date_notnull IS NULL" to "date_notnull IS NULL OR 
                                 date_notnull = 0"
      if dealing with an OUTER JOIN, otherwise 
      "date_notnull IS NULL" to "date_notnull = 0"
      as was done before.
      
      Note:
      The bug was originally reported as different result on first 
      and second execution of SP. The reason was that during first
      execution the query was correctly rewritten to an inner join
      due to a null-rejecting predicate. On second execution the
      "IS NULL" -> "= 0" rewrite was done because there was no outer
      join. The real problem, though, was incorrect date/datetime 
      IS NULL handling for OUTER JOINs.
      fb110da7
    • Dmitry Shulga's avatar
    • Tor Didriksen's avatar
    • Dmitry Shulga's avatar
      Fixed bug#11753738 (formely known as bug#45235) - 5.1 DOES NOT SUPPORT 5.0-ONLY · 8867ad80
      Dmitry Shulga authored
      SYNTAX TRIGGERS IN ANY WAY
      
      Table with triggers which were using deprecated (5.0-only) syntax became
      unavailable for any DML and DDL after upgrade to 5.1 version of server.
      Attempt to execute any statement on such a table resulted in parsing
      error reported. Since this included DROP TRIGGER and DROP TABLE
      statements (actually, the latter was allowed but was not functioning
      properly for such tables) it was impossible to fix the problem without
      manual operations on .TRG and .TRN files in data directory.
      
      The problem was that failure to parse trigger body (due to 5.0-only
      syntax) when opening trigger file for a table prevented the table
      from being open. This made all operations on the table impossible
      (except DROP TABLE which due to peculiarity in its implementation
      dropped the table but left trigger files around).
      
      This patch solves this problem by silencing error which occurs when
      we parse trigger body during table open. Error message is preserved
      for the future use and table is marked as having a broken trigger.
      We also try to analyze parse tree to recover trigger name, which
      will be needed in order to drop the broken trigger. DML statements
      which invoke triggers on the table marked as having broken trigger
      are prohibited and emit saved error message. The same happens for
      DDL which change triggers except DROP TRIGGER and DROP TABLE which
      try their best to do what was requested. Table becomes no longer
      marked as having broken trigger when last such trigger is dropped.
      8867ad80
  2. 09 Jun, 2011 9 commits
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · cfb1f299
      Marko Mäkelä authored
      cfb1f299
    • Marko Mäkelä's avatar
      Disable a debug assertion that was added to track down Bug#12612184. · c8419fac
      Marko Mäkelä authored
      row_build(): The record may contain null BLOB pointers when the server
      is rolling back an insert that was interrupted by a server crash.
      c8419fac
    • Dmitry Shulga's avatar
    • Dmitry Shulga's avatar
      Follow-up for patch of bug#11764334. · ef3c145d
      Dmitry Shulga authored
      ef3c145d
    • Dmitry Shulga's avatar
    • Dmitry Shulga's avatar
      Fixed bug#11764334 (formerly bug#57156): ALTER EVENT CHANGES · 1cc304e3
      Dmitry Shulga authored
      THE EVENT STATUS.
      
      Any ALTER EVENT statement on a disabled event enabled it back
      (unless this ALTER EVENT statement explicitly disabled the event).
      
      The problem was that during processing of an ALTER EVENT statement
      value of status field was overwritten unconditionally even if new
      value was not specified explicitly. As a consequence this field
      was set to default value for status which corresponds to ENABLE.
      
      The solution is to check if status field was explicitly specified in
      ALTER EVENT statement before assigning new value to status field.
      1cc304e3
    • Dmitry Lenev's avatar
      Fix for bug #11759990 - "52354: 'CREATE TABLE .. LIKE ... ' · 95f1b676
      Dmitry Lenev authored
      STATEMENTS FAIL".
      
      Attempt to execute CREATE TABLE LIKE statement on a MyISAM
      table with INDEX or DATA DIRECTORY options specified as a
      source resulted in "MyISAM table '...' is in use..." error.
      According to our documentation such a statement should create
      a copy of source table with DATA/INDEX DIRECTORY options
      omitted.
      
      The problem was that new implementation of CREATE TABLE LIKE
      statement in 5.5 tried to copy value of INDEX and DATA DIRECTORY
      parameters from the source table. Since in description of source
      table this parameters also included name of this table, attempt
      to create target table with these parameter led to file name
      conflict and error.
      
      This fix addresses the problem by preserving documented and
      backward-compatible behavior. I.e. by ensuring that contents
      of DATA/INDEX DIRECTORY clauses for the source table is
      ignored when target table is created.
      95f1b676
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · b1fc801a
      Marko Mäkelä authored
      b1fc801a
    • Marko Mäkelä's avatar
      BLOB instrumentation for Bug#12612184 Race condition in row_upd_clust_rec() · 6d20340c
      Marko Mäkelä authored
      If UNIV_DEBUG or UNIV_BLOB_LIGHT_DEBUG is enabled, add
      !rec_offs_any_null_extern() assertions, ensuring that records do not
      contain null pointers to externally stored columns in inappropriate
      places.
      
      btr_cur_optimistic_update(): Assert !rec_offs_any_null_extern().
      Incomplete records must never be updated or deleted. This assertion
      will cover also the pessimistic route.
      
      row_build(): Assert !rec_offs_any_null_extern(). Search tuples must
      never be built from incomplete index entries.
      
      row_rec_to_index_entry(): Assert !rec_offs_any_null_extern() unless
      ROW_COPY_DATA is requested. ROW_COPY_DATA is used for
      multi-versioning, and therefore it might be valid to copy the most
      recent (uncommitted) version while it contains a null pointer to
      off-page columns.
      
      row_vers_build_for_consistent_read(),
      row_vers_build_for_semi_consistent_read(): Assert !rec_offs_any_null_extern()
      on all versions except the most recent one.
      
      trx_undo_prev_version_build(): Assert !rec_offs_any_null_extern() on
      the previous version.
      
      rb:682 approved by Sunny Bains
      6d20340c
  3. 08 Jun, 2011 1 commit
  4. 07 Jun, 2011 3 commits
  5. 06 Jun, 2011 5 commits
  6. 03 Jun, 2011 11 commits
  7. 02 Jun, 2011 1 commit
  8. 01 Jun, 2011 2 commits