An error occurred fetching the project authors.
- 22 May, 2006 1 commit
-
-
andrey@lmy004. authored
- Scheduler is either initialized at server start or never. Starting & stopping is now suspending & resuming. - The scheduler has clear OO interface - Now all calls to the scheduler are synchronous - GLOBAL event_scheduler uses thd::sys_var_tmp (see set_var.cc) - External API is encapsulated into class Events - Includes fixes for all comments of Kostja's review of 19.05.2005 Starting to merge into 5.1-release (5.1.10) and push
-
- 12 May, 2006 2 commits
-
-
gluh@eagle.intranet.mysql.r18.ru authored
replaced get_field(MEM_ROOT *mem, Field *field) with get_field(MEM_ROOT *mem, Field *field, String *res). It allows to avoid strlen().
-
gluh@eagle.intranet.mysql.r18.ru authored
-
- 11 May, 2006 1 commit
-
-
- 10 May, 2006 2 commits
-
-
BUG#19010: Fix issues with that ALTER TABLE from auto-partitioned NDB table doesn't work unless primary key exists on table.
-
msvensson@neptunus.(none) authored
-
- 08 May, 2006 1 commit
-
-
serg@sergbook.mysql.com authored
-
- 04 May, 2006 1 commit
-
-
tnurnberg@mysql.com authored
mysqldump / SHOW CREATE TABLE will show the NEXT available value for the PK, rather than the *first* one that was available (that named in the original CREATE TABLE ... AUTO_INCREMENT = ... statement). This should produce correct and robust behaviour for the obvious use cases -- when no data were inserted, then we'll produce a statement featuring the same value the original CREATE TABLE had; if we dump with values, INSERTing the values on the target machine should set the correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT = ... to do that). Lastly, just the CREATE statement (with no data) for a table that saw inserts would still result in a table that new values could safely be inserted to). There seems to be no robust way however to see whether the next_ID field is > 1 because it was set to something else with CREATE TABLE ... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column in the table (but no initial value was set with AUTO_INCREMENT = ...) and then one or more rows were INSERTed, counting up next_ID. This means that in both cases, we'll generate an AUTO_INCREMENT = ... clause in SHOW CREATE TABLE / mysqldump. As we also show info on, say, charsets even if the user did not explicitly give that info in their own CREATE TABLE, this shouldn't be an issue. As per above, the next_ID will be affected by any INSERTs that have taken place, though. This /should/ result in correct and robust behaviour, but it may look non-intuitive to some users if they CREATE TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have SHOW CREATE TABLE give them a different value (say, CREATE TABLE ... AUTO_INCREMENT = 1006), so the docs should possibly feature a caveat to that effect. It's not very intuitive the way it works now (with the fix), but it's *correct*. We're not storing the original value anyway, if we wanted that, we'd have to change on-disk representation? If we do dump/load cycles with empty DBs, nothing will change. This changeset includes an additional test case that proves that tables with rows will create the same next_ID for AUTO_INCREMENT = ... across dump/restore cycles. Confirmed by support as likely solution for client's problem.
-
- 03 May, 2006 2 commits
-
-
monty@mysql.com authored
Added support for key_block_size to MyISAM. Simplify interface to 'new Key' to make it easier to add new key options. mysqld option --new is used to define where key options are printed. (In 5.3 we should move all key options to after key part definition to avoid problem with reserved names) Fixed some compiler warnings and a memory leak in ssl
-
brian@zim.(none) authored
-
- 02 May, 2006 2 commits
-
-
aivanov@mysql.com authored
-
gluh@eagle.intranet.mysql.r18.ru authored
added I_S.REFARENTIAL_CONSTRAINTS table
-
- 30 Apr, 2006 2 commits
-
-
serg@sergbook.mysql.com authored
-
-
- 13 Apr, 2006 1 commit
-
-
acurtis@xiphis.org authored
" Configure support for server plugins "
-
- 10 Apr, 2006 1 commit
-
-
- 07 Apr, 2006 1 commit
-
-
andrey@lmy004. authored
This also should fix 17493 and 17346, and probably 16397 (not tested). WL#1034 (Internal CRON) (post-review commit)
-
- 01 Apr, 2006 1 commit
-
-
reggie@linux.site authored
-
- 31 Mar, 2006 1 commit
-
-
reggie@linux.site authored
-
- 29 Mar, 2006 1 commit
-
-
monty@mysql.com authored
Added missing DBUG_xxx_RETURN statements Fixed some usage of not initialized variables (as found by valgrind) Ensure that we don't remove locked tables used as name locks from open table cache until unlock_table_names() are called. This was fixed by having drop_locked_name() returning any table used as a name lock so that we can free it in unlock_table_names() This will allow Tomas to continue with his work to use namelocks to syncronize things. Note: valgrind still produces a lot of warnings about using not initialized code and shows memory loss errors when running the ndb tests
-
- 20 Mar, 2006 2 commits
-
-
gluh@eagle.intranet.mysql.r18.ru authored
additional check for subselect
-
gluh@eagle.intranet.mysql.r18.ru authored
Crash happened when one selected data from one of INFORMATION_SCHEMA tables and in order to build its contents server had to open view which used stored function and table or view on which one had not global or database-level privileges (e.g. had only table-level or had no privileges at all). The crash was caused by usage of check_grant() function, which assumes that either number of tables to be inspected by it is limited explicitly or table list used and thd->lex->query_tables_own_last value correspond to each other (the latter should be either 0 or point to next_global member of one of elements of this table list), in conditions when above assumptions were not true. This fix just explicitly limits number of tables to be inspected. Other negative effects which are caused by the fact that thd->lex->query_tables_own_last might not be set properly during processing of I_S tables are less disastrous and will be reported and fixed separetely.
-
- 10 Mar, 2006 1 commit
-
-
anozdrin@mysql.com authored
w/o definer if --skip-grant-tables specified. The previous patch does not allow to specify empty host name in DEFINER-clause explicitly.
-
- 09 Mar, 2006 2 commits
-
-
anozdrin@mysql.com authored
-
anozdrin@mysql.com authored
-
- 07 Mar, 2006 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
NULL value handling
-
- 28 Feb, 2006 2 commits
-
-
andrey@lmy004. authored
fix for bug#17793 (Scheduler uses class event_timed should be Event_timed)
-
andrey@lmy004. authored
- now when the event is created and STARTS is omitted then STARTS is implicitly CURRENT_TIMESTAMP - This CS also fixed incorrect presentation of STARTS/ENDS in I_S.EVENTS (incorporated review changes)
-
- 27 Feb, 2006 1 commit
-
-
SergeyV@selena. authored
-
- 25 Feb, 2006 1 commit
-
-
guilhem@mysql.com authored
and new binlog format called "mixed" (which is statement-based except if only row-based is correct, in this cset it means if UDF or UUID is used; more cases could be added in later 5.1 release): SET GLOBAL|SESSION BINLOG_FORMAT=row|statement|mixed|default; the global default is statement unless cluster is enabled (then it's row) as in 5.1-alpha. It's not possible to use SET on this variable if a session is currently in row-based mode and has open temporary tables (because CREATE TEMPORARY TABLE was not binlogged so temp table is not known on slave), or if NDB is enabled (because NDB does not support such change on-the-fly, though it will later), of if in a stored function (see below). The added tests test the possibility or impossibility to SET, their effects, and the mixed mode, including in prepared statements and in stored procedures and functions. Caveats: a) The mixed mode will not work for stored functions: in mixed mode, a stored function will always be binlogged as one call and in a statement-based way (e.g. INSERT VALUES(myfunc()) or SELECT myfunc()). b) for the same reason, changing the thread's binlog format inside a stored function is refused with an error message. c) the same problems apply to triggers; implementing b) for triggers will be done later (will ask Dmitri). Additionally, as the binlog format is now changeable by each user for his session, I remove the implication which was done at startup, where row-based automatically set log-bin-trust-routine-creators to 1 (not possible anymore as a user can now switch to stmt-based and do nasty things again), and automatically set --innodb-locks-unsafe-for-binlog to 1 (was anyway theoretically incorrect as it disabled phantom protection). Plus fixes for compiler warnings.
-
- 24 Feb, 2006 1 commit
-
-
andrey@lmy004. authored
WL#1034 (Internal CRON)
-
- 22 Feb, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 21 Feb, 2006 1 commit
-
-
andrey@lmy004. authored
post-review fixes
-
- 20 Feb, 2006 2 commits
-
-
andrey@lmy004. authored
WL#1032 sql_mode setting was disregarded during create/alter event and wasn't set during event execution. (post-review small fixes)
-
andrey@lmy004. authored
WL#1034
-
- 16 Feb, 2006 3 commits
-
-
reggie@big_geek. authored
Also, moved some of the code out of handler.h and into partition specific files for better separation. Also, moved some of the C funcs into partition_info as formal C++ methods
-
aivanov@mysql.com authored
-
andrey@lmy004. authored
| INTERVAL_VALUE | INTERVAL_FIELD | | 20 | 20 MINUTE | the second one should be without the value
-
- 14 Feb, 2006 2 commits
-
-
andrey@lmy004. authored
- fix for bug#16423 (Events: SHOW CREATE EVENT doesn't work) - this Changeset commits makes CREATE/UPDATE/DELETE EVENT real DDL statements by committing the currently open transaction before they are executed. - this Changeset also fixes a trailing space problem since the very early days of the internal cron - adds sophisticated checking of whether mysql.event was tampered accidentally or with purpose by an user. - adds a lot of inline function documentation - documents everything left uncodumented - INTERVAL_XXXX to XXX in I_S.EVENTS.INTERVAL_FIELD WL#1034 (Internal CRON)
-
gluh@eagle.intranet.mysql.r18.ru authored
Bug#16695 Reading I_S.PARTITIONS with pre-5.1.6 partitioned tables crashes server issue a warning in case of error during table opening
-