1. 06 Nov, 2007 7 commits
  2. 05 Nov, 2007 2 commits
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Merge aelkin@bk-internal.mysql.com:/home/bk/mysql-5.0-rpl · 27636d56
      aelkin/elkin@koti.dsl.inet.fi authored
      into  koti.dsl.inet.fi:/home/elkin/MySQL/TEAM/FIXES/5.0/bug28597-log_name_upgrade
      27636d56
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #28597 Replication doesn't start after upgrading to 5.1.18 · 571f8be4
      aelkin/elkin@koti.dsl.inet.fi authored
      Since bug@20166, which replaced the binlog file name generating to base
      on pidfile_name instead of the previous glob_hostname, the binlog file
      name suddenly started to be stored solely in the absolute path format,
      including a case when --log-bin option meant a relative path.
      What's more serious, the path for binlog file can lead unrequestedly 
      to pid-file directory so that after any proper fix for this bug
      there might be similar to the bug report consequences for one who
      upgrades from post-fix-bug@20166-pre-fix-bug@28597 to post-fix-bug@28597.
      
      Fixed with preserving`pidfile_name' (intr.by bug@20166) but stripping
      off its directory part. This restores the original logics of storing
      the names in compatible with --log-bin option format and with the
      requirement for --log-bin ralative path to corresond to the data directory.
      Side effects for this fix:
      
      effective fixing bug@27070, refining its test;
      ensuring no overrun for buff can happen anymore (Bug#31836 
      insufficient space reserved for the suffix of relay log file name);
      bug#31837  --remove_file $MYSQLTEST_VARDIR/tmp/bug14157.sql missed
      in rpl_temporary.test;
      fixes Bug@28603  Invalid log-bin default location;
      571f8be4
  3. 30 Oct, 2007 2 commits
  4. 29 Oct, 2007 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #27571 asynchronousity in setting mysql_`query`::error and · 27436f0b
      aelkin/elkin@koti.dsl.inet.fi authored
                 Query_log_event::error_code
      
      A query can perform completely having the local var error of mysql_$query
      zero, where $query in insert, update, delete, load,
      and be  binlogged with error_code e.g KILLED_QUERY while there is no
      reason do to so.
      That can happen because Query_log_event consults thd->killed flag to
      evaluate error_code.
      
      Fixed with implementing a scheme suggested and partly implemented at
      time of bug@22725 work-on. error_status is cached immediatly after the
      control leaves the main rows-loop and that instance always corresponds
      to `error' the local of mysql_$query functions. The cached value
      is passed to Query_log_event constructor, not the default thd->killed
      which can be changed in between of the caching and the constructing.
      27436f0b
  5. 26 Oct, 2007 2 commits
  6. 24 Oct, 2007 3 commits
  7. 23 Oct, 2007 15 commits
  8. 22 Oct, 2007 4 commits
  9. 21 Oct, 2007 4 commits