1. 10 Jun, 2008 1 commit
  2. 03 Jun, 2008 1 commit
  3. 22 May, 2008 1 commit
  4. 21 May, 2008 1 commit
  5. 18 May, 2008 2 commits
    • gshchepa/uchum@host.loc's avatar
      Merge host.loc:/work/bugs/5.0-bugteam-36676 · 80b16212
      gshchepa/uchum@host.loc authored
      into  host.loc:/work/bk/5.0-bugteam
      80b16212
    • gshchepa/uchum@host.loc's avatar
      Fixed bug#36676: multiupdate using LEFT JOIN updates only · 2459d3a9
      gshchepa/uchum@host.loc authored
                       first row or fails with an error:
        ERROR 1022 (23000): Can't write; duplicate key in table ''
      
      The server uses intermediate temporary table to store updated
      row data.  The first column of this table contains rowid.
      Current server implementation doesn't reset NULL flag of that
      column even if the server fills a column with rowid.
      To keep each rowid unique, there is an unique index.
      An insertion into an unique index takes into account NULL
      flag of key value and ignores real data if NULL flag is set.
      So, insertion of actually different rowids may lead to two
      kind of problems.  Visible effect of each of these problems
      depends on an initial engine type of temporary table:
      
      1. If multiupdate initially creates temporary table as
      a MyISAM table (a table contains blob columns, and the
      create_tmp_table function assumes, that this table is
      large), it inserts only one single row and updates
      only rows with one corresponding rowid. Other rows are
      silently ignored. 
      
      2. If multiupdate initially creates MEMORY temporary
      table, fills it with data and reaches size limit for
      MEMORY tables (max_heap_table_size), multiupdate
      converts MEMORY table into MyISAM table and fails
      with an error:
        ERROR 1022 (23000): Can't write; duplicate key in table ''
      
      
      Multiupdate has been fixed to update the NULL flag of
      temporary table rowid columns.
      2459d3a9
  6. 17 May, 2008 1 commit
  7. 16 May, 2008 9 commits
  8. 15 May, 2008 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ · 573828aa
      cmiller@zippy.cornsilk.net authored
      	slave
      
      The stored-routine code took the contents of the (lowest) parser
      and copied it directly to the binlog, which causes problems if there
      is a special case of interpretation at the parser level -- which 
      there is, in the "/*!VER */" comments.  The trailing "*/" caused
      errors on the slave, naturally.
      
      Now, since by that point we have /properly/ created parse-tree (as 
      the rest of the server should do!) for the stored-routine CREATE, we
      can construct a perfect statement from that information, instead of
      writing uncertain information from an unknown parser state.  
      Fortunately, there's already a function nearby that does exactly 
      that.
      ---
      Update for Bug#36570.  Qualify routine names with db name when
      writing to the binlog ONLY if the source text is qualified.
      573828aa
  9. 14 May, 2008 1 commit
  10. 13 May, 2008 3 commits
  11. 12 May, 2008 2 commits
    • gshchepa/uchum@host.loc's avatar
      Merge host.loc:/work/bugs/5.0-bugteam-36055 · 486ef1ba
      gshchepa/uchum@host.loc authored
      into  host.loc:/work/bk/5.0-bugteam
      486ef1ba
    • gshchepa/uchum@host.loc's avatar
      Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables · 1e7be565
      gshchepa/uchum@host.loc authored
      The REPAIR TABLE ... USE_FRM query silently corrupts data of tables
      with old .FRM file version.
      The mysql_upgrade client program or the REPAIR TABLE query (without
      the USE_FRM clause) can't prevent this trouble, because in the
      common case they don't upgrade .FRM file to compatible structure.
      
      1. Evaluation of the REPAIR TABLE ... USE_FRM query has been
         modified to reject such tables with the message:
         "Failed repairing incompatible .FRM file".
      
      2. REPAIR TABLE query (without USE_FRM clause) evaluation has been
         modified to upgrade .FRM files to current version.
      
      3. CHECK TABLE ... FOR UPGRADE query evaluation has been modified
         to return error status when .FRM file has incompatible version.
      
      4. mysql_upgrade and mysqlcheck client programs call CHECK TABLE
         FOR UPGRADE and REPAIR TABLE queries, so their behaviors have
         been changed too to upgrade .FRM files with incompatible
         version numbers.
      1e7be565
  12. 08 May, 2008 2 commits
  13. 06 May, 2008 3 commits
  14. 05 May, 2008 1 commit
  15. 02 May, 2008 5 commits
  16. 01 May, 2008 4 commits
  17. 30 Apr, 2008 1 commit
  18. 28 Apr, 2008 1 commit