- 10 Dec, 2003 5 commits
-
-
unknown authored
into mysql.com:/home/kostja/mysql/mysql-4.0-1790
-
unknown authored
into mysql.com:/home/kostja/mysql/mysql-4.0-1790
-
unknown authored
SQL_BIG_RESULT used": now BIT_AND() always returns 18446744073709551615 if no rows were found. This patch also fixes bug #1972: "BIT_AND() and BIT_OR() still return a *signed* 64bit value" mysql-test/r/func_group.result: followup to fix for bug #1790 BIT_AND() result in GROUP BY different when SQL_BIG_RESULT used": test results fixed bug #1972 "BIT_AND() and BIT_OR() still return a *signed* 64bit value": results of new tests mysql-test/t/func_group.test: added tests for bug #1972 "BIT_AND() and BIT_OR() still return a *signed* 64bit value"
-
unknown authored
into mysql.com:/my/mysql-4.0
-
unknown authored
-
- 09 Dec, 2003 15 commits
-
-
unknown authored
into mysql.com:/home/kostja/mysql/mysql-4.0-1335
-
unknown authored
--disable_query_log was not a good idea, Serg says mysql-test/r/group_by.result: bug #1335 tests followup: --disable_query_log was not a good idea, Serg says tests results updated
-
unknown authored
into mysql.com:/my/mysql-4.0
-
unknown authored
Added checking of return value from malloc() in reg_init() client/mysqltest.c: Added comment dbug/dbug.c: Removed not needed test mysys/charset.c: Added checking of return value from my_once_alloc() regex/reginit.c: Abort if out of memory in reg_init() (unlikely) sql/item_strfunc.cc: Added comment
-
unknown authored
into sanja.is.com.ua:/home/bell/mysql/bk/work-qc-4.0
-
unknown authored
-
unknown authored
mysql-test/r/group_by.result: test results fixed mysql-test/t/group_by.test: added few explicit tests for bug #1335
-
unknown authored
into sanja.is.com.ua:/home/bell/mysql/bk/work-qc-4.0
-
unknown authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.0 sql/mysqld.cc: Auto merged
-
unknown authored
sql/mysqld.cc: code cleanup
-
unknown authored
-
unknown authored
into mysql.com:/my/mysql-4.0 sql/mysqld.cc: Auto merged
-
unknown authored
-
unknown authored
-
unknown authored
-
- 08 Dec, 2003 3 commits
-
-
unknown authored
Otherwise, if the previous run ended with a crash, and the PID was 1234, and you have rebooted the machine and the new PID is 99 then in the PID file you will have 9934. Note: users of mysqld_safe did not have the problem because this script deletes the PID file before starting mysqld.
-
unknown authored
into mysql.com:/home/mysql_src/mysql-4.0
-
unknown authored
The constructor of Rotate_log_event used when we are rotating our binlog or relay log, should not assume that there is a nonzero THD available. For example, when we are reacting to SIGHUP, the THD is 0. In fact we don't need to use the THD in this constructor; we can do like for Stop_log_event, and use the minimal Log_event constructor. If we were allowed to put Unix-specific commands in the testsuite, I'd add a test for this (<sigh>). sql/log.cc: A comment to warn that thd can be 0. The part about LOG_EVENT_FORCED_ROTATE_F is just to avoid segfault; this flag is already removed in 4.1 anyway. sql/log_event.cc: A comment. sql/log_event.h: The constructor of Rotate_log_event used when we are rotating our binlog or relay log, should not assume that there is a nonzero THD available. For example, when we are reacting to SIGHUP, the THD is 0. In fact we don't need to use the THD in this constructor; we can do like for Stop_log_event, and use the minimal Log_event constructor. This fixes BUG#2045 "Sending SIGHUP to mysqld crashes it if running with --log-bin"
-
- 07 Dec, 2003 3 commits
-
-
unknown authored
into gluh.mysql.r18.ru:/home/gluh/mysql-4.0.defweek sql/mysqld.cc: Auto merged
-
unknown authored
New formats added for 'week()' function and 'default_week_format' option(4 - 7). Next formats is supported now: *Value* *Meaning* `0' Week starts on Sunday; First Sunday of the year starts week 1. Week() returns 0-53. `1' Week starts on Monday; Weeks numbered according to ISO 8601:1988. Week() returns 0-53. `2' Week starts on Sunday; First Sunday of the year starts week 1. Week() returns 1-53. `3' Week starts on Monday; Weeks numbered according to ISO 8601:1988. Week() returns 1-53. `4' Week starts on Sunday; Weeks numbered according to ISO 8601:1988. Week() returns 0-53. `5' Week starts on Monday; First Monday of the year starts week 1. Week() returns 0-53. `6' Week starts on Sunday; Weeks numbered according to ISO 8601:1988. Week() returns 1-53. `7' Week starts on Monday; First Monday of the year starts week 1. Week() returns 1-53. mysql-test/r/func_time.result: Test for 'default_week_format' option and 'week' function mysql-test/t/func_time.test: Test for 'default_week_format' option and 'week' function sql/item_timefunc.cc: WL#1175 more default_week_formats for iso compatibility sql/mysql_priv.h: WL#1175 more default_week_formats for iso compatibility sql/mysqld.cc: WL#1175 more default_week_formats for iso compatibility sql/time.cc: WL#1175 more default_week_formats for iso compatibility
-
unknown authored
into gluh.mysql.r18.ru:/home/gluh/mysql-4.0.pass sql/sql_parse.cc: Auto merged
-
- 05 Dec, 2003 2 commits
- 04 Dec, 2003 12 commits
-
-
unknown authored
into mysql.com:/home/kostja/mysql/mysql-4.0-root
-
unknown authored
into mysql.com:/home/mysql_src/mysql-4.0
-
unknown authored
we change THD::system_thread from a 'bool' to a bitmap to be able to distinguish between delayed-insert threads and slave threads. - Fix for BUG#1701 "Update from multiple tables" (one line in sql_parse.cc, plus a new test rpl_multi_update.test). That's just adding an initialization. sql/repl_failsafe.cc: comment to warn about this unused code sql/slave.cc: Now thd->system_thread is a bitmap, not a bool. sql/sql_class.h: 'bool' for THD::system_thread is not accurate enough; sometimes we need to distinguish between delayed-insert threads and slave threads; so changing THD::system_thread to a bitmap (uint). sql/sql_insert.cc: thd.system_thread is now a bitmap sql/sql_parse.cc: We need to initialize thd->lex.select_lex.options in mysql_init_query(); it's already initialized in dispatch_command() but replication calls mysql_parse() directly, thus bypassing dispatch_command(). Not initing it here leads to a query influencing the next query, in the slave SQL thread. The initialization in dispatch_command() must be kept as this command uses the variable in tests, even when the command was not a query (i.e. when mysql_init_query() was not called).
-
unknown authored
into mysql.com:/home/kostja/mysql/mysql-4.0-1790
-
unknown authored
into mysql.com:/bk/mysql-4.0
-
unknown authored
VC++Files/InstallShield/4.0.XX-classic/String Tables/0009-English/value.shl: This should not be the product version; it must match Default.shl VC++Files/InstallShield/4.0.XX-gpl/String Tables/0009-English/value.shl: This should not be the product version; it must match Default.shl VC++Files/InstallShield/4.0.XX-pro/String Tables/0009-English/value.shl: This should not be the product version; it must match Default.shl
-
unknown authored
into mysql.com:/my/mysql-4.0
-
unknown authored
move bdb/innodb tests to right places mysql-test/r/bdb.result: Update results after test changes mysql-test/r/innodb.result: Update results after test changes mysql-test/r/multi_update.result: Update results after test changes mysql-test/t/bdb.test: Move bdb tests here mysql-test/t/innodb.test: Move innodb test here mysql-test/t/multi_update.test: move bdb/innodb tests to repective test sql/mysqld.cc: Allow space in service names
-
unknown authored
into mysql.com:/home/dlenev/src/mysql-4.0-tsbug
-
unknown authored
if we failed to classify integer as datetime in Field_datetime::store(). Stylistic clean-ups. sql/field.cc: Fix undeterministic behaviour of year check if we failed to classify integer as datetime Stylistic clean-ups.
-
unknown authored
into mysql.com:/home/mysql_src/mysql-4.0
-
unknown authored
The problem was that when the slave SQL thread reads a hot relay log (hot = the one being written to by the slave I/O thread), it must have the LOCK_log. It already took it for read_log_event(), but needs it also for check_binlog_magic(). This should fix all recently reported failures of the rpl_max_relay_size test in 4.1 and 5.0 (though the bug exists since 4.0, it showed up first in 5.0). sql/slave.cc: Fix for BUG#2011 "rare race condition producing "binlog has bad magic number" error in slave". The problem was that when the slave SQL thread reads a hot relay log (hot = the one being written to by the slave I/O thread), it must have the LOCK_log. It already took it for read_log_event(), but needs it also for check_binlog_magic().
-