- 09 Dec, 2003 1 commit
-
-
unknown authored
sql/mysqld.cc: code cleanup
-
- 05 Dec, 2003 2 commits
- 04 Dec, 2003 14 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().
-
unknown authored
into gluh.mysql.r18.ru:/home/gluh/mysql-4.0.bugfssl
-
unknown authored
-
- 03 Dec, 2003 3 commits
- 02 Dec, 2003 8 commits
-
-
unknown authored
into mysql.com:/home/mysql_src/mysql-4.0
-
unknown authored
into mysql.com:/home/psergey/mysql-4.0
-
unknown authored
BitKeeper/etc/logging_ok: Logging to logging@openlogging.org accepted
-
unknown authored
into mysql.com:/home/dlenev/src/mysql-4.0-tsbg
-
unknown authored
about it". Now numbers representing illegal timestamps are converted to 0 value if they are stored as timestamp or datetime. This behaviour is consistent with manual and with behaviour of string -> timestamp conversion. mysql-test/r/type_datetime.result: Added test if ranges are checked during integer, string -> timestamp conversion mysql-test/r/type_timestamp.result: Added test if ranges are checked during integer, string -> datetime conversion mysql-test/t/type_datetime.test: Added test if ranges are checked during integer, string -> datetime conversion mysql-test/t/type_timestamp.test: Added test if ranges are checked during integer, string -> timestamp conversion sql/field.cc: Checks of month, day, hour, minute and second ranges were added to storing of integer into Field_datetime and Field_timestamp and so for integer -> datetime, timestamp conversion.
-
unknown authored
SQL_BIG_RESULT used': - BIT_AND now returns BIGINT UNSIGNED - in case there were no matching rows BIT_AND returns 18446744073709551615 (but not NULL), BIT_OR returns 0 (but not NULL). That's how Monty wants it and how is described in our docs. include/my_global.h: Added definition for ULONGLONG_MAX. This is also a check that ULL type specifier can be used on all supported platforms. mysql-test/r/func_group.result: bug #1790, post-review work: test results fixed sql/item_sum.cc: small cleanup sql/item_sum.h: few style fixes. BIT_AND and BIT_OR now are both BIGINT UNSIGNED
-
unknown authored
instead of Log_event::Log_event(THD*, ...) when the event is built in the master to be written in the binlog. Rand_log_event already used the good constructor, so there really is no reason for Intvar_log_event to be an exception. This fixes a test failure of last night (which appeared after I removed a useless e.server_id=thd->server_id in log.cc; in fact this line was not useless because it hid the bad constructor). Replication tests pass, with Valgrind too. sql/log_event.h: There is no reason that Intvar_log_event's constructor calls Log_event::Log_event() instead of Log_event::Log_event(THD*, ...) when the event is built in the master to be written in the binlog. Rand_log_event already used the good constructor, so there really is no reason for Intvar_log_event to be an exception. This fixes a test failure of last night (which appeared after I removed a useless e.server_id=thd->server_id in log.cc; in fact this line was not useless because it hid the bad constructor).
-
unknown authored
into mysql.com:/home/kostja/mysql/mysql-4.0-1790
-
- 01 Dec, 2003 2 commits
- 28 Nov, 2003 7 commits
-
-
unknown authored
-
unknown authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.0
-
unknown authored
It happens that mysql->client_next->client_next=mysql and mysql_close() goes into infinite loop. Results vary from simple sigsegv (FreeBSD), to hard system lockup (Linux) :)
-
unknown authored
into mysql.com:/my/mysql-4.0
-
unknown authored
mysql-test/r/range.result: test for range optimzier bug mysql-test/t/range.test: test for range optimzier bug
-
unknown authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.0
-
unknown authored
-
- 27 Nov, 2003 3 commits