1. 21 Mar, 2008 2 commits
  2. 19 Mar, 2008 1 commit
    • aelkin/andrei@mysql1000.(none)'s avatar
      Bug #35178 INSERT_ID not written to binary log for inserts against BLACKHOLE backed tables · b581227f
      aelkin/andrei@mysql1000.(none) authored
      binlogging of insert into a autoincrement blackhole table ignored
      an explicit set insert_id.
      
      Fixed with refining of the blackhole's insert method to call
      update_auto_increment() that prepares binlogging the insert query 
      with the preceeding set insert_id.
      
      Note, as the engine does not store any actual data one has to explicitly
      provide to the server with the value of the autoincrement column via
      set insert_id. Otherwise binlogging will happend with the default 
      set insert_id=1.
      b581227f
  3. 17 Mar, 2008 1 commit
    • aelkin/andrei@mysql1000.(none)'s avatar
      Bug #18199 PURGE BINARY LOGS fails silently with missing logs; · 18dab9d7
      aelkin/andrei@mysql1000.(none) authored
      Bug #18453  Warning/error message if there is a mismatch between ...
       
      There were three problems:
       
       1. the reported lack of warnings for the BEFORE syntax of PURGE;
       2. the similar lack of warnings for the TO syntax;
       3. incompatible behaviour between the two in that the latter blanked out
          regardlessly of presence or lack the actual file corresponding to
          an index record; the former version gave up at the first mismatch.
      
      fixed with deploying the warning's generation and synronizing logics of 
      purge_logs() and purge_logs_before_date().
      my_stat() is called in either of two branches of purge_logs() (responsible
      for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax.
      If there is no actual binlog file, my_stat returns NULL and my_delete is
      not invoked.
      A critical error is reported to the user if a file from the index
      could not be retrieved info about or deleted with a system error code
      different than ENOENT.
      18dab9d7
  4. 14 Mar, 2008 1 commit
  5. 13 Mar, 2008 1 commit
  6. 12 Mar, 2008 4 commits
  7. 11 Mar, 2008 1 commit
  8. 10 Mar, 2008 2 commits
  9. 08 Mar, 2008 1 commit
  10. 07 Mar, 2008 3 commits
  11. 06 Mar, 2008 2 commits
  12. 05 Mar, 2008 2 commits
  13. 03 Mar, 2008 5 commits
    • joerg@trift2.'s avatar
      687d2131
    • sergefp@mysql.com's avatar
      BUG#34945: "ref_or_null queries that are null_rejecting and have a null value crash mysql" · b779af55
      sergefp@mysql.com authored
      - Apply Eric Bergen's patch: in join_read_always_key(), move ha_index_init() call
        to before the late NULLs filtering code.
      - Backport function comments from 6.0.
      b779af55
    • kaa@kaamos.(none)'s avatar
      Merge kaamos.(none):/data/src/opt/bug31781/my50 · 232e9d3c
      kaa@kaamos.(none) authored
      into  kaamos.(none):/data/src/opt/mysql-5.0-opt
      232e9d3c
    • kaa@kaamos.(none)'s avatar
      Fix for bug #31781: multi-table UPDATE with temp-pool enabled fails · bd53f960
      kaa@kaamos.(none) authored
                          with errno 17
      
      my_create() did not perform any checks for the case when a file is
      successfully created by a call to open(), but the call to
      my_register_filename() later fails because the number of open files
      has exceeded the my_open_files limit. This can happen on platforms 
      which do not have getrlimit(), and hence we do not know the real limit
      for open files. In such a case an error was returned to a caller
      although the file has actually been created. Since callers assume
      my_create() to return an error only when it failed to create a file,
      they did not perform any cleanups, leaving an 'orphaned' file on the
      file system.
      
      Fixed by adding a check for the above case to my_create() and ensuring
      the newly created file is deleted before returning an error.
      
      Creating a deterministic test case in the test suite is impossible,
      because the exact steps required to reproduce the above situation
      depend on the platform and/or environment (OS per-user limits, queries
      executed by previous tests, startup parameters). The patch was
      manually tested on Windows using examples posted in the bug report.
      bd53f960
    • gluh@mysql.com/mgluh.(none)'s avatar
      test case fix · fc1ae077
      gluh@mysql.com/mgluh.(none) authored
      fc1ae077
  14. 02 Mar, 2008 1 commit
  15. 01 Mar, 2008 1 commit
  16. 29 Feb, 2008 7 commits
  17. 28 Feb, 2008 5 commits