An error occurred fetching the project authors.
- 10 Jan, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
2nd version During tmp tables cleanup we get the handler for temporary table and delete table using handler method.
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 07 Dec, 2006 1 commit
-
-
kostja@bodhi.local authored
Bug#4968 "Stored procedure crash if cursor opened on altered table" Bug#19733 "Repeated alter, or repeated create/drop, fails" Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from stored procedure." Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing" Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server" Test cases for bugs 4968, 19733, 6895 will be added in 5.0. Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE statements in stored routines or as prepared statements caused incorrect results (and crashes in versions prior to 5.0.25). In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options). The problem of bugs 4968, 19733, 19282 and 6895 was that functions mysql_prepare_table, mysql_create_table and mysql_alter_table were not re-execution friendly: during their operation they used to modify contents of LEX (members create_info, alter_info, key_list, create_list), thus making the LEX unusable for the next execution. In particular, these functions removed processed columns and keys from create_list, key_list and drop_list. Search the code in sql_table.cc for drop_it.remove() and similar patterns to find evidence. The fix is to supply to these functions a usable copy of each of the above structures at every re-execution of an SQL statement. To simplify memory management, LEX::key_list and LEX::create_list were added to LEX::alter_info, a fresh copy of which is created for every execution. The problem of crashing bug 22060 stemmed from the fact that the above metnioned functions were not only modifying HA_CREATE_INFO structure in LEX, but also were changing it to point to areas in volatile memory of the execution memory root. The patch solves this problem by creating and using an on-stack copy of HA_CREATE_INFO (note that code in 5.1 already creates and uses a copy of this structure in mysql_create_table()/alter_table(), but this approach didn't work well for CREATE TABLE SELECT statement).
-
- 05 Dec, 2006 2 commits
-
-
-
Problem: replication of LC_TIME_NAMES didn't work. Thus, INSERTS or UPDATES using date_format() always worked with en_US on the slave side. Fix: adding ONE_SHOT implementation for LC_TIME_NAMES.
-
- 30 Nov, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Fixed compiler warnings (detected by VC++): - Removed not used variables - Added casts - Fixed wrong assignments to bool - Fixed wrong calls with bool arguments - Added missing argument to store(longlong), which caused wrong store method to be called.
-
- 27 Nov, 2006 1 commit
-
-
Problems (appear only under some circumstances): 1. we get a reference to a deleted table searching in the thd->handler_tables_hash in the mysql_ha_read(). 2. DBUG_ASSERT(table->file->inited == handler::NONE); assert fails in the close_thread_table(). Fix: end open index scans and table scans and remove references to the tables from the handler tables hash. After this preparation it is safe to close the tables. The close can no longer fail on open index/table scans and the closed table will not be used again by handler functions.
-
- 09 Nov, 2006 1 commit
-
-
The problem was that any VIEW columns had always implicit derivation. Fix: derivation is now copied from the original expression given in VIEW definition. For example: - a VIEW column which comes from a string constant in CREATE VIEW definition have now coercible derivation. - a VIEW column having COLLATE clause in CREATE VIEW definition have now explicit derivation.
-
- 01 Nov, 2006 2 commits
-
-
petr/cps@mysql.com/owlet.local authored
(4.1 version, with post-review fixes) The fix for another Bug (6439) limited FROM_UNIXTIME() to TIMESTAMP_MAX_VALUE which is 2145916799 or 2037-12-01 23:59:59 GMT, however unix timestamp in general is not considered to be limited by this value. All dates up to power(2,31)-1 are valid. This patch extends allowed TIMESTAMP range so, that max TIMESTAMP value is power(2,31)-1. It also corrects FROM_UNIXTIME() and UNIX_TIMESTAMP() functions, so that max allowed UNIX_TIMESTAMP() is power(2,31)-1. FROM_UNIXTIME() is fixed accordingly to allow conversion of dates up to 2038-01-19 03:14:07 UTC. The patch also fixes CONVERT_TZ() function to allow extended range of dates. The main problem solved in the patch is possible overflows of variables, used in broken-time representation to time_t conversion (required for UNIX_TIMESTAMP).
-
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.
-
- 30 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
If the user has specified --max-connections=N or --table-open-cache=M options to the server, a warning could be given that some values were recalculated, and table-open-cache could be assigned greater value. Note that both warning and increase of table-open-cache were totally harmless. This patch fixes recalculation code to ensure that table-open-cache will be never increased automatically and that a warning will be given only if some values had to be decreased due to operating system limits. No test case is provided because we neither can't predict nor control operating system limits for maximal number of open files.
-
- 19 Oct, 2006 1 commit
-
-
istruewing@chilla.local authored
Backport from 5.1. Raised STACK_MIN_SIZE for Debian GNU/Linux Sid, Linux kernel 2.6.16, gcc version 3.3.6 (Debian 1:3.3.6-13), libc6-dbg 2.3.6.ds1-4, Pentium4 (x86), BUILD/compile-pentium-debug-max Raised about 100 Bytes above the required minimum.
-
- 17 Oct, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
list using a function When executing dependent subqueries they are re-inited and re-exec() for each row of the outer context. The cause for the bug is that during subquery reinitialization/re-execution, the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join() and the local variable in 'sortorder' in create_sort_index(), which is allocated by make_unireg_sortorder(). Care must be taken not to allocate anything into the thread's memory pool while re-initializing query plan structures between subquery re-executions. All such items mush be cached and reused because the thread's memory pool is freed at the end of the whole query. Note that they must be cached and reused even for queries that are not otherwise cacheable because otherwise it will grow the thread's memory pool every time a cacheable query is re-executed. We provide additional members to the JOIN structure to store references to the items that need to be cached.
-
- 13 Oct, 2006 1 commit
-
-
evgen@moonbone.local authored
The mysql_alter_table() was able to rename only a table. The view/table renaming code is moved from the function rename_tables to the new function called do_rename(). The mysql_alter_table() function calls it when it needs to rename a view.
-
- 27 Sep, 2006 2 commits
-
-
cmiller@zippy.cornsilk.net authored
The STACK_MIN_SIZE is currently set to 8192, when we actually need (emperically discovered) 9236 bytes to raise an fatal error, on Ubuntu Dapper Drake, libc6 2.3.6-0ubuntu2, Linux kernel 2.6.15-27-686, on x86. I'm taking that as a new lower bound, plus 100B of wiggle-room for sundry word sizes and stack behaviors. The added test verifies in a cross-platform way that there are no gaps between the space that we think we need and what we actually need to report an error. DOCUMENTERS: This also adds "let" to the mysqltest commands that evaluate an argument to expand variables therein. (Only right of the "=", of course.)
-
gluh@mysql.com/gluh.(none) authored
-
- 25 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
Presence of a subquery in the ON expression of a join should not block merging the view that contains this join. Before this patch the such views were converted into into temporary table views.
-
- 21 Sep, 2006 1 commit
-
-
dlenev@mockturtle.local authored
this key does not stop" (version for 5.0 only). UPDATE statement which WHERE clause used key and which invoked trigger that modified field in this key worked indefinetely. This problem occured because in cases when UPDATE statement was executed in update-on-the-fly mode (in which row is updated right during evaluation of select for WHERE clause) the new version of the row became visible to select representing WHERE clause and was updated again and again. We already solve this problem for UPDATE statements which does not invoke triggers by detecting the fact that we are going to update field in key used for scanning and performing update in two steps, during the first step we gather information about the rows to be updated and then doing actual updates. We also do this for MULTI-UPDATE and in its case we even detect situation when such fields are updated in triggers (actually we simply assume that we always update fields used in key if we have before update trigger). The fix simply extends this check which is done in check_if_key_used()/ QUICK_SELECT_I::check_if_keys_used() routine/method in such way that it also detects cases when field used in key is updated in trigger. As nice side-effect we have more precise and thus more optimal perfomance-wise check for the MULTI-UPDATE. Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to better reflect that boolean predicate. Note that this check is implemented in much more elegant way in 5.1
-
- 12 Sep, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
The problem was that if after FLUSH TABLES WITH READ LOCK the user issued DROP/ALTER PROCEDURE/FUNCTION the operation would fail (as expected), but after UNLOCK TABLE any attempt to execute the same operation would lead to the error 1305 "PROCEDURE/FUNCTION does not exist", and an attempt to execute any stored function will also fail. This happened because under FLUSH TABLES WITH READ LOCK we couldn't open and lock mysql.proc table for update, and this fact was erroneously remembered by setting mysql_proc_table_exists to false, so subsequent statements believed that mysql.proc doesn't exist, and thus that there are no functions and procedures in the database. As a solution, we remove mysql_proc_table_exists flag completely. The reason is that this optimization didn't work most of the time anyway. Even if open of mysql.proc failed for some reason when we were trying to call a function or a procedure, we were setting mysql_proc_table_exists back to true to force table reopen for the sake of producing the same error message (the open can fail for number of reasons). The solution could have been to remember the reason why open failed, but that's a lot of code for optimization of a rare case. Hence we simply remove this optimization.
-
- 08 Sep, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
-
- 04 Sep, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
1003: Incorrect table name in multi-table DELETE the set of tables to delete from actually references then tables in the other list, e.g: DELETE alias_of_t1 FROM t1 alias_of_t1 WHERE .... is a valid statement. So we must turn off table name syntactical validity check for alias_of_t1 because it's not a table name (even if it looks like one). In order to do that we add a special flag (TL_OPTION_ALIAS) to disable the name checking for the aliases in multi-table DELETE.
-
- 24 Aug, 2006 1 commit
-
-
anozdrin/alik@alik. authored
User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error.
-
- 23 Aug, 2006 1 commit
-
-
anozdrin/alik@alik. authored
User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error.
-
- 22 Aug, 2006 1 commit
-
-
sergefp@mysql.com authored
-
- 21 Aug, 2006 1 commit
-
-
sergefp@mysql.com authored
-
- 19 Aug, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
Corrected build issues : the build can not be conditional. to keep a unique source .tar.gz distribution.
-
- 17 Aug, 2006 1 commit
-
-
jimw@rama.(none) authored
Fix when __attribute__() is stubbed out, add ATTRIBUTE_FORMAT() for specifying __attribute__((format(...))) safely, make more use of the format attribute, and fix some of the warnings that this turns up (plus a bonus unrelated one).
-
- 15 Aug, 2006 1 commit
-
-
evgen@sunlight.local authored
SELECT right instead of INSERT right was required for an insert into to a view. This wrong behaviour appeared after the fix for bug #20989. Its intention was to ask only SELECT right for all tables except the very first for a complex INSERT query. But that patch has done it in a wrong way and lead to asking a wrong access right for an insert into a view. The setup_tables_and_check_access() function now accepts two want_access parameters. One will be used for the first table and the second for other tables.
-
- 28 Jul, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
'conc_sys' test Concurrent execution of SELECT involing at least two INFORMATION_SCHEMA tables, DROP DATABASE statement and DROP TABLE statement could have resulted in stalled connection for this SELECT statement. The problem was that for the first query of a join there was a race between select from I_S.TABLES and DROP DATABASE, and the error (no such database) was prepared to be send to the client, but the join processing was continued. On second query to I_S.COLUMNS there was a race with DROP TABLE, but this error (no such table) was downgraded to warning, and thd->net.report_error was reset. And so neither result nor error was sent to the client. The solution is to stop join processing once it is clear we are going to report a error, and also to downgrade to warnings file system errors like 'no such database' (unless we are in the 'SHOW' command), because I_S is designed not to use locks and the query to I_S should not abort if something is dropped in the middle. No test case is provided since this bug is a result of a race, and is timing dependant. But we test that plain SHOW TABLES and SHOW COLUMNS give a error if there is no such database or a table respectively.
-
- 27 Jul, 2006 1 commit
-
-
anozdrin/alik@booka. authored
Fix for BUG#16676: Database CHARSET not used for stored procedures The problem in BUG#16211 is that CHARSET-clause of the return type for stored functions is just ignored. The problem in BUG#16676 is that if character set is not explicitly specified for sp-variable, the server character set is used instead of the database one. The fix has two parts: - always store CHARSET-clause of the return type along with the type definition in mysql.proc.returns column. "Always" means that CHARSET-clause is appended even if it has not been explicitly specified in CREATE FUNCTION statement (this affects BUG#16211 only). Storing CHARSET-clause if it is not specified is essential to avoid changing character set if the database character set is altered in the future. NOTE: this change is not backward compatible with the previous releases. - use database default character set if CHARSET-clause is not explicitly specified (this affects both BUG#16211 and BUG#16676). NOTE: this also breaks backward compatibility.
-
- 22 Jul, 2006 1 commit
-
-
sergefp@mysql.com authored
-
- 21 Jul, 2006 1 commit
-
-
tsmith@maint1.mysql.com authored
-
- 20 Jul, 2006 2 commits
-
-
sergefp@mysql.com authored
Add implementations of Item_func_{nop,not}_all::neg_transformer
-
tsmith/tim@siva.hindu.god authored
- Adapt it to work with the handlerton class
-
- 14 Jul, 2006 1 commit
-
-
to avoid the potential security problem. (see bug #15195: Security Breach with MERGE table)
-
- 04 Jul, 2006 1 commit
-
-
bar@mysql.com authored
(implemented by by Josh Chamas)
-
- 01 Jul, 2006 1 commit
-
-
dlenev@mysql.com authored
NDB table". SQL-layer was not marking fields which were used in triggers as such. As result these fields were not always properly retrieved/stored by handler layer. So one might got wrong values or lost changes in triggers for NDB, Federated and possibly InnoDB tables. This fix solves the problem by marking fields used in triggers appropriately. Also this patch contains the following cleanup of ha_ndbcluster code: We no longer rely on reading LEX::sql_command value in handler in order to determine if we can enable optimization which allows us to handle REPLACE statement in more efficient way by doing replaces directly in write_row() method without reporting error to SQL-layer. Instead we rely on SQL-layer informing us whether this optimization applicable by calling handler::extra() method with HA_EXTRA_WRITE_CAN_REPLACE flag. As result we no longer apply this optimzation in cases when it should not be used (e.g. if we have on delete triggers on table) and use in some additional cases when it is applicable (e.g. for LOAD DATA REPLACE). Finally this patch includes fix for bug#20728 "REPLACE does not work correctly for NDB table with PK and unique index". This was yet another problem which was caused by improper field mark-up. During row replacement fields which weren't explicity used in REPLACE statement were not marked as fields to be saved (updated) so they have retained values from old row version. The fix is to mark all table fields as set for REPLACE statement. Note that in 5.1 we already solve this problem by notifying handler that it should save values from all fields only in case when real replacement happens.
-
- 29 Jun, 2006 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
user name is calculated on function execution stage instead of parse stage
-
- 26 Jun, 2006 1 commit
-
-
ingo@mysql.com authored
Addendum fixes after changing the condition variable for the global read lock. The stress test suite revealed some deadlocks. Some were related to the new condition variable (COND_global_read_lock) and some were general problems with the global read lock. It is now necessary to signal COND_global_read_lock whenever COND_refresh is signalled. We need to wait for the release of a global read lock if one is set before every operation that requires a write lock. But we must not wait if we have locked tables by LOCK TABLES. After setting a global read lock a thread waits until all write locks are released.
-
- 21 Jun, 2006 1 commit
-
-
gkodinov@mysql.com authored
schemas The function check_one_table_access() called to check access to tables in SELECT/INSERT/UPDATE was doing additional checks/modifications that don't hold in the context of setup_tables_and_check_access(). That's why the check_one_table() was split into two : the functionality needed by setup_tables_and_check_access() into check_single_table_access() and the rest of the functionality stays in check_one_table_access() that is made to call the new check_single_table_access() function.
-