An error occurred fetching the project authors.
- 02 Apr, 2007 1 commit
-
-
msvensson@pilot.blaudden authored
-
- 28 Mar, 2007 1 commit
-
-
tsmith@siva.hindu.god authored
Thanks to Martin Friebe for finding and submitting a fix for this bug! A table with maximum number of key segments and maximum length key name would have a corrupted .frm file, due to an incorrect calculation of the complete key length. Now the key length is computed correctly (I hope) :-) MyISAM would reject a table with the maximum number of keys and the maximum number of key segments in all keys. It would allow one less than this total maximum. Now MyISAM accepts a table defined with the maximum. (This is a very minor issue.)
-
- 16 Mar, 2007 1 commit
-
-
serg@janus.mylan authored
s/ulonglong/key_part_map/, comments
-
- 11 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
sql_yacc.yy: WL3527: updated the diff to use correct parser words table.cc: WL3527: exteneded the fix for bug #20604 to fit the new variables sql_select.cc: WL3527: renamed used_keys to covering_keys
-
- 09 Mar, 2007 1 commit
-
-
kroki/tomash@moonlight.home authored
The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
-
- 06 Mar, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
Bug 18914 (Calling certain SPs from triggers fail) Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02') Bug 21825 (Incorrect message error deleting records in a table with a trigger for inserting) Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency error) Bug 25345 (Cursors from Functions) This fix resolves a long standing issue originally reported with bug 8407, which affect the behavior of Stored Procedures, Stored Functions and Trigger in many different ways, causing symptoms reported by all the bugs listed. In all cases, the root cause of the problem traces back to 8407 and how the server locks tables involved with sub statements. Prior to this fix, the implementation of stored routines would: - compute the transitive closure of all the tables referenced by a top level statement - open and lock all the tables involved - execute the top level statement "transitive closure of tables" means collecting: - all the tables, - all the stored functions, - all the views, - all the table triggers - all the stored procedures involved, and recursively inspect these objects definition to find more references to more objects, until the list of every object referenced does not grow any more. This mechanism is known as "pre-locking" tables before execution. The motivation for locking all the tables (possibly) used at once is to prevent dead locks. One problem with this approach is that, if the execution path the code really takes during runtime does not use a given table, and if the table is missing, the server would not execute the statement. This in particular has a major impact on triggers, since a missing table referenced by an update/delete trigger would prevent an insert trigger to run. Another problem is that stored routines might define SQL exception handlers to deal with missing tables, but the server implementation would never give user code a chance to execute this logic, since the routine is never executed when a missing table cause the pre-locking code to fail. With this fix, the internal implementation of the pre-locking code has been relaxed of some constraints, so that failure to open a table does not necessarily prevent execution of a stored routine. In particular, the pre-locking mechanism is now behaving as follows: 1) the first step, to compute the transitive closure of all the tables possibly referenced by a statement, is unchanged. 2) the next step, which is to open all the tables involved, only attempts to open the tables added by the pre-locking code, but silently fails without reporting any error or invoking any exception handler is the table is not present. This is achieved by trapping internal errors with Prelock_error_handler 3) the locking step only locks tables that were successfully opened. 4) when executing sub statements, the list of tables used by each statements is evaluated as before. The tables needed by the sub statement are expected to be already opened and locked. Statement referencing tables that were not opened in step 2) will fail to find the table in the open list, and only at this point will execution of the user code fail. 5) when a runtime exception is raised at 4), the instruction continuation destination (the next instruction to execute in case of SQL continue handlers) is evaluated. This is achieved with sp_instr::exec_open_and_lock_tables() 6) if a user exception handler is present in the stored routine, that handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be trapped by stored routines. If no handler exists, then the runtime execution will fail as expected. With all these changes, a side effect is that view security is impacted, in two different ways. First, a view defined as "select stored_function()", where the stored function references a table that may not exist, is considered valid. The rationale is that, because the stored function might trap exceptions during execution and still return a valid result, there is no way to decide when the view is created if a missing table really cause the view to be invalid. Secondly, testing for existence of tables is now done later during execution. View security, which consist of trapping errors and return a generic ER_VIEW_INVALID (to prevent disclosing information) was only implemented at very specific phases covering *opening* tables, but not covering the runtime execution. Because of this existing limitation, errors that were previously trapped and converted into ER_VIEW_INVALID are not trapped, causing table names to be reported to the user. This change is exposing an existing problem, which is independent and will be resolved separately.
-
- 05 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
can be specified Currently MySQL allows one to specify what indexes to ignore during join optimization. The scope of the current USE/FORCE/IGNORE INDEX statement is only the FROM clause, while all other clauses are not affected. However, in certain cases, the optimizer may incorrectly choose an index for sorting and/or grouping, and produce an inefficient query plan. This task provides the means to specify what indexes are ignored/used for what operation in a more fine-grained manner, thus making it possible to manually force a better plan. We do this by extending the current IGNORE/USE/FORCE INDEX syntax to: IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}] so that: - if no FOR is specified, the index hint will apply everywhere. - if MySQL is started with the compatibility option --old_mode then an index hint without a FOR clause works as in 5.0 (i.e, the index will only be ignored for JOINs, but can still be used to compute ORDER BY). See the WL#3527 for further details.
-
- 28 Feb, 2007 1 commit
-
-
kostja@bodhi.local authored
therefore the logic associated with it never worked.
-
- 12 Feb, 2007 2 commits
-
-
tnurnberg@mysql.com/sin.azundris.com authored
ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales. This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from being used. Now if 0xff makes an appearance, we find a character not used in the enum and use that as a separator. If no such character exists, we throw an error. Any solution would have broken some sort of existing behaviour. This solution should serve both fractions (those with 0xff and those with ',' in their enums), but WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/ That is, mysqldump with their current server, and restore when upgrading to one with this patch.
-
gluh@mysql.com/eagle.(none) authored
The crash happens because second filling of the same I_S table happens in case of subselect with order by. table->sort.io_cache previously allocated in create_sort_index() is deleted during second filling (function get_schema_tables_result). There are two places where I_S table can be filled: JOIN::exec and create_sort_index(). To fix the bug we should check if the table was already filled in one of these places and skip processing of the table in second.
-
- 31 Jan, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Two problems here: Problem 1: While constructing the join columns list the optimizer does as follows: 1. Sets the join_using_fields/natural_join members of the right JOIN operand. 2. Makes a "table reference" (TABLE_LIST) to parent the two tables. 3. Assigns the join_using_fields/is_natural_join of the wrapper table using join_using_fields/natural_join of the rightmost table 4. Sets join_using_fields to NULL for the right JOIN operand. 5. Passes the parent table up to the same procedure on the upper level. Step 1 overrides the the join_using_fields that are set for a nested join wrapping table in step 4. Fixed by making a designated variable SELECT_LEX::prev_join_using to pass the data from step 1 to step 4 without destroying the wrapping table data. Problem 2: The optimizer checks for ambiguous columns while transforming NATURAL JOIN/JOIN USING to JOIN ON. While doing that there was no distinction between columns that are used in the generated join condition (where ambiguity can be checked) and the other columns (where ambiguity can be checked only when resolving references coming from outside the JOIN construct itself). Fixed by allowing the non-USING columns to be present in multiple copies in both sides of the join and moving the ambiguity check to the place where unqualified references to the join columns are resolved (find_field_in_natural_join()).
-
- 29 Jan, 2007 1 commit
-
-
serg@janus.mylan authored
index_read(), index_read_idx(), index_read_last(), and records_in_range() - instead of 'uint keylen' argument take 'ulonglong keypart_map', a bitmap showing which keyparts are present in the key value. Fallback method is provided for handlers that are lagging behind.
-
- 28 Jan, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Removed a lot of compiler warnings Removed not used variables, functions and labels Initialize some variables that could be used unitialized (fatal bugs) %ll -> %l
-
- 22 Jan, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Fixed wrong merge that disabled 'make test' Renamed all suppress files to end in '.supp' Don't give "skipped %d bytes from file" warnings in 5.0
-
- 12 Jan, 2007 1 commit
-
-
tnurnberg@mysql.com/sin.azundris.com authored
ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales. This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from being used. Now if 0xff makes an appearance, we find a character not used in the enum and use that as a separator. If no such character exists, we throw an error. Any solution would have broken some sort of existing behaviour. This solution should serve both fractions (those with 0xff and those with ',' in their enums), but WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/ That is, mysqldump with their current server, and restore when upgrading to one with this patch.
-
- 09 Jan, 2007 1 commit
-
-
tnurnberg@mysql.com/sin.azundris.com authored
ENUMs weren't allowed to have character 0xff, a perfectly good character in many locales. This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from being used (because they too would get converted to 0xff on load). Now if 0xff makes an appearance, we find a character not used in the enum and use that as a separator. If no such character exists, we throw an error. Any solution would have broken some sort of existing behaviour. This solution should serve both fractions (those with 0xff and those with ',' in their enums), but WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/ That is, mysqldump with their current server, and restore when upgrading to one with this patch. (port of the original 4.1 patch. incorporates some suggestions by kaamos.)
-
- 31 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Corrected spelling in copyright text Makefile.am: Don't update the files from BitKeeper Many files: Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header Adjusted year(s) in copyright header Many files: Added GPL copyright text Removed files: Docs/Support/colspec-fix.pl Docs/Support/docbook-fixup.pl Docs/Support/docbook-prefix.pl Docs/Support/docbook-split Docs/Support/make-docbook Docs/Support/make-makefile Docs/Support/test-make-manual Docs/Support/test-make-manual-de Docs/Support/xwf
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 15 Dec, 2006 1 commit
-
-
svoj@mysql.com/april.(none) authored
Having broken .frm, particulary number of field names does not match number of fields, causes server crash. Refuse to open a table if number of field names in a table is not equal to number of fields in a table. No test case, since it requires broken .frm file.
-
- 14 Dec, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
-
- 07 Dec, 2006 1 commit
-
-
cbell/Chuck@suse.vabb.com authored
Please see worklog for details on files changed.
-
- 02 Dec, 2006 1 commit
-
-
brian@zim.(none) authored
This finishes the work (someone) started to remove FIELD_ types and use the Enum MYSQL types. The second part to this is to actually deprecate the FIELD defines in mysql_com.h
-
- 30 Nov, 2006 2 commits
-
-
The reason of this valgrind's compaint is not a bug but rather a feature of bitwise ops: for any value of the byte x x | 1 -> 1, and x & 0 -> 0. x, being a null_byte part of record[1] can be left unassigned even after ha_innobase::index_read_idx because the above and still be correct. Addding a check memory upon the invocation of the function can detect this fact long before record[1], old record, is eventually passed to my_write. Fixed with initialization of record[1]'s null_bytes part in open_table_from_share.
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables - Changed some ulong parameters/variables to ulonglong (possible serious bug) - Added casts to get rid of safe assignment from longlong to long (and similar) - Added casts to function parameters - Fixed signed/unsigned compares - Added some constructores to structures - Removed some not portable constructs Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown" (Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
-
- 28 Nov, 2006 1 commit
-
-
dli@dev3-76.dev.cn.tlan authored
ndb - fiexed for bug#15021, binlog_index table become inconsistent if errors during purge of binlogs. improved the original patch, changed if/else to switch/case.
-
- 27 Nov, 2006 2 commits
-
-
monty@mysql.com/nosik.monty.fi authored
Initialize key_part->type on open. This caused key_copy() to fail for bit_fields. (key_copy is used in HANDLER and opt_range)
-
evgen@moonbone.local authored
If a view was created with the DEFINER security and later the definer user was dropped then a SELECT from the view throws the error message saying that there is no definer user is registered. This is ok for a root but too much for a mere user. Now the st_table_list::prepare_view_securety_context() function reveals the absence of the definer only to a superuser and throws the 'access denied' error to others.
-
- 26 Nov, 2006 2 commits
-
-
monty@mysql.com/nosik.monty.fi authored
Added missing DBUG_RETURN statements (in mysqldump.c) Added missing enums Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.
-
The reason of this valgrind's compaint is not a bug but rather a feature of bitwise ops: for any value of the byte x x | 1 -> 1, and x & 0 -> 0. x, being a null_byte part of record[1] can be left unassigned even after ha_innobase::index_read_idx because the above and still be correct. Addding a check memory upon the invocation of the function can detect this fact long before record[1], old record, is eventually passed to my_write. Fixed with initialization of record[1]'s null_bytes part in open_table_from_share.
-
- 21 Nov, 2006 2 commits
-
-
monty@mysql.com/nosik.monty.fi authored
Moved .progress files into the log directory Moved 'cluster' database tables into the MySQL database, to not have 'cluster' beeing a reserved database name Fixed bug where mysqld got a core dump when trying to use a table created by MySQL 3.23 Fixed some compiler warnings Fixed small memory leak in libmysql Note that this doesn't changeset doesn't include the new mysqldump.c code required to run some tests. This will be added when I merge 5.0 to 5.1
-
mats@romeo.(none) authored
Removing DBUG_DUMP printouts for valgrind builds since they trigger warnings. Removing valgrind memory checks completely. Removing bzero() of record when opening table that was added earlier.
-
- 20 Nov, 2006 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
(Mostly in DBUG_PRINT() and unused arguments) Fixed bug in query cache when used with traceing (--with-debug) Fixed memory leak in mysqldump Removed warnings from mysqltest scripts (replaced -- with #)
-
- 17 Nov, 2006 1 commit
-
-
open_table_from_share did not initialize table->record members. that was interpreted as the error by valgrind. Fixed with bzero-ing the members if compilation with -DHAVE_purify.
-
- 01 Nov, 2006 2 commits
-
-
monty@mysql.com/nosik.monty.fi authored
Fixed some possible fatal wrong arguments to printf() style functions Initialized some not initialized variables Fixed bug in stored procedure and continue handlers (Fixes Bug#22150)
-
igor@rurik.mysql.com authored
This is a performance issue for queries with subqueries evaluation of which requires filesort. Allocation of memory for the sort buffer at each evaluation of a subquery may take a significant amount of time if the buffer is rather big. With the fix we allocate the buffer at the first evaluation of the subquery and reuse it at each subsequent evaluation.
-
- 19 Oct, 2006 1 commit
-
-
We miss some records sometimes using RANGE method if we have partial key segments. Example: Create table t1(a char(2), key(a(1))); insert into t1 values ('a'), ('xx'); select a from t1 where a > 'x'; We call index_read() passing 'x' key and HA_READ_AFTER_KEY flag in the handler::read_range_first() wich is wrong because we have a partial key segment for the field and might miss records like 'xx'. Fix: don't use open segments in such a case.
-
- 16 Oct, 2006 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 13 Oct, 2006 2 commits
-
-
petr/cps@mysql.com/owlet.local authored
Bug #21785 "Server crashes after rename of the log table" and Bug #21966 "Strange warnings on create like/repair of the log tables" According to the patch, from now on, one should use RENAME to perform a log table rotation (this should also be reflected in the manual). Here is a sample: use mysql; CREATE TABLE IF NOT EXISTS general_log2 LIKE general_log; RENAME TABLE general_log TO general_log_backup, general_log2 TO general_log; The rules for Rename of the log tables are following: IF 1. Log tables are enabled AND 2. Rename operates on the log table and nothing is being renamed to the log table. DO 3. Throw an error message. ELSE 4. Perform rename. The very RENAME query will go the the old (backup) table. This is consistent with the behavoiur we have with binlog ROTATE LOGS statement. Other problems, which are solved by the patch are: 1) Now REPAIR of the log table is exclusive operation (as it should be), this also eliminates lock-related warnings. and 2) CREATE LIKE TABLE now usese usual read lock on the source table rather then name lock, which is too restrictive. This way we get rid of another log table-related warning, which occured because of the above fact (as a side-effect, name lock resulted in a warning).
-
dli@dev3-76.dev.cn.tlan authored
ndb - fixed for BUG#15021, binlog_index table become inconsistent if errors during purge of binlogs. if EMFILE error occured while purging binary logs, stop purging logs and report error message to user.
-
- 29 Sep, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
We use the condition from CHECK OPTION twice handling UPDATE command. First we construnct 'update_cond' AND 'option_cond' condition to select records to be updated, then we check the 'option_cond' for the updated row. The problem is that first 'AND' condition is optimized during the 'select' which can break 'option_cond' structure, so it will be unusable for the sectond use - to check the updated row. Possible soultion is either use copy of the condition in the first use or to make optimization less traumatic for the operands. I picked the first one.
-