An error occurred fetching the project authors.
- 19 Feb, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Several problems fixed: 1. There was a "catch-all" context initialization in setup_tables() that was causing the table that we insert into to be visible in the SELECT part of an INSERT .. SELECT .. statement with no tables in its FROM clause. This was making sure all the under-initialized contexts in various parts of the code are not left uninitialized. Fixed by removing the "catch-all" statement and initializing the context in the parser. 2. Incomplete name resolution context when resolving the right-hand values in the ON DUPLICATE KEY UPDATE ... part of an INSERT ... SELECT ... caused columns from NATURAL JOIN/JOIN USING table references in the FROM clause of the select to be unavailable. Fixed by establishing a proper name resolution context. 3. When setting up the special name resolution context for problem 2 there was no check for cases where an aggregate function without a GROUP BY effectively takes the column from the SELECT part of an INSERT ... SELECT unavailable for ON DUPLICATE KEY UPDATE. Fixed by checking for that condition when setting up the name resolution context.
-
- 16 Feb, 2007 1 commit
-
-
evgen@moonbone.local authored
UPDATE contains wrong data if the SELECT employs a temporary table. If the UPDATE values of the INSERT .. SELECT .. ON DUPLICATE KEY UPDATE statement contains fields from the SELECT part and the select employs a temporary table then those fields will contain wrong values because they aren't corrected to get data from the temporary table. The solution is to add these fields to the selects all_fields list, to store pointers to those fields in the selects ref_pointer_array and to access them via Item_ref objects. The substitution for Item_ref objects is done in the new function called Item_field::update_value_transformer(). It is called through the item->transform() mechanism at the end of the select_insert::prepare() function.
-
- 09 Feb, 2007 1 commit
-
-
evgen@moonbone.local authored
inserted. The select_insert::send_eof() function now resets LAST_INSERT_ID variable if no rows were inserted.
-
- 06 Feb, 2007 1 commit
-
-
evgen@moonbone.local authored
updated. INSERT ... ON DUPLICATE KEY UPDATE reports that a record was updated when the duplicate key occurs even if the record wasn't actually changed because the update values are the same as those in the record. Now the compare_record() function is used to check whether the record was changed and the update of a record reported only if the record differs from the original one.
-
- 22 Jan, 2007 1 commit
-
-
evgen@moonbone.local authored
When inserting into a join-based view the update fields from the ON DUPLICATE KEY UPDATE wasn't checked to be from the table being inserted into and were silently ignored. The new check_view_single_update() function is added to check that insert/update fields are being from the same single table of the view.
-
- 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
-
- 11 Dec, 2006 1 commit
-
-
kostja@bodhi.local authored
on altered table" and Bug#19733 "Repeated alter, or repeated create/drop, fails"
-
- 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).
-
- 01 Nov, 2006 1 commit
-
-
svoj@mysql.com/april.(none) authored
tables,alter table Deadlock could happen if there are delayed insert + flush tables + alter table running concurrently. This is fixed by removing a redundant mutex lock when killing a delayed thread.
-
- 06 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored procedures. However, 4.1 had some bugs that were fixed in 5.0 by the patch for bug#21726, and this patch is a backport of those fixes. Namely, in 4.1 it fixes: - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific). - LAST_INSERT_ID() could return the value generated by current statement if the call happens after the generation, like in CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT); INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID()); - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
-
- 02 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Non-upper-level INSERTs (the ones in the body of stored procedure, stored function, or trigger) into a table that have AUTO_INCREMENT column didn't affected the result of LAST_INSERT_ID() on this level. The problem was introduced with the fix of bug 6880, which in turn was introduced with the fix of bug 3117, where current insert_id value was remembered on the first call to LAST_INSERT_ID() (bug 3117) and was returned from that function until it was reset before the next _upper-level_ statement (bug 6880). The fix for bug#21726 brings back the behaviour of version 4.0, and implements the following: remember insert_id value at the beginning of the statement or expression (which at that point equals to the first insert_id value generated by the previous statement), and return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID. Thus, the value returned by LAST_INSERT_ID() is not affected by values generated by current statement, nor by LAST_INSERT_ID(expr) calls in this statement. Version 5.1 does not have this bug (it was fixed by WL 3146).
-
- 28 Sep, 2006 1 commit
-
-
evgen@moonbone.local authored
On an INSERT into an updatable but non-insertable view an error message was issued stating the view being not updatable. This can lead to a confusion of a user. A new error message is introduced. Is is showed when a user tries to insert into a non-insertable view.
-
- 20 Sep, 2006 1 commit
-
-
istruewing@chilla.local authored
Bug#20627 - INSERT DELAYED does not honour auto_increment_* variables INSERT DELAYED ignored an explicitly set INSERT_ID and session specific auto_increment_* variables. The problem was that the inserts are done by a system thread, which does not have access to the session variables of the user thread. On a proposal of Guilhem I fixed it so that the variables are copied to the data structure for every delayed row. The system thread sets its session variables from these values.
-
- 16 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
containing a select statement that uses an aggregating IN subquery. Added a parameter to the function fix_prepare_information to restore correctly the having clause for the second execution. Saved andor structure of the having conditions at the proper moment before any calls of split_sum_func2 that could modify the having structure adding new Item_ref objects. (These additions, are produced not with the statement mem_root, but rather with the execution mem_root.)
-
- 12 Sep, 2006 1 commit
-
-
timour/timka@lamia.home authored
The cause of the bug was an incomplete fix for bug 18080. The problem was that setup_tables() unconditionally reset the name resolution context to its 'tables' argument, which pointed to the first table of an SQL statement. The bug fix limits resetting of the name resolution context in setup_tables() only in the cases when the context was not set by earlier parser/optimizer phases.
-
- 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.
-
- 19 Jul, 2006 1 commit
-
-
REPLACE ... SELECT would require INSERT privileges on certain tables when SELECT really suffices. Require INSERT only on target table.
-
- 05 Jul, 2006 1 commit
-
-
guilhem@mysql.com authored
auto_increment breaks binlog": if slave's table had a higher auto_increment counter than master's (even though all rows of the two tables were identical), then in some cases, REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate statement-based (it inserted different values on slave from on master). write_record() contained a "thd->next_insert_id=0" to force an adjustment of thd->next_insert_id after the update or replacement. But it is this assigment introduced indeterminism of the statement on the slave, thus the bug. For ON DUPLICATE, we replace that assignment by a call to handler::adjust_next_insert_id_after_explicit_value() which is deterministic (does not depend on slave table's autoinc counter). For REPLACE, this assignment can simply be removed (as REPLACE can't insert a number larger than thd->next_insert_id). We also move a too early restore_auto_increment() down to when we really know that we can restore the value.
-
- 04 Jul, 2006 1 commit
-
-
gkodinov@mysql.com authored
When compiling INSERT statements the check whether columns are provided values depends on the flag whether a field is used in that query (Field::query_id). However the check for updatability of VIEW columns (check_view_insertability()) was calling fix_fields() and thus setting the Field::query_id even for the view fields that are not referenced in the current INSERT statement. So the correct check for columns without default values ( check_that_all_fields_are_given_values() ) is assuming that all the VIEW columns were mentioned in the INSERT field list and was issuing no warnings or errors. Fixed check_view_insertability() to turn off the flag whether or not to set Field::query_id (THREAD::set_query_id) before calling fix fields and restore it when it's done.
-
- 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.
-
- 26 Jun, 2006 3 commits
-
-
konstantin@mysql.com authored
Bug#19022 "Memory bug when switching db during trigger execution" Bug#17199 "Problem when view calls function from another database." Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements" Documentation note: this patch introduces a change in behaviour of prepared statements. This patch adds a few new invariants with regard to how THD::db should be used. These invariants should be preserved in future: - one should never refer to THD::db by pointer and always make a deep copy (strmake, strdup) - one should never compare two databases by pointer, but use strncmp or my_strncasecmp - TABLE_LIST object table->db should be always initialized in the parser or by creator of the object. For prepared statements it means that if the current database is changed after a statement is prepared, the database that was current at prepare remains active. This also means that you can not prepare a statement that implicitly refers to the current database if the latter is not set. This is not documented, and therefore needs documentation. This is NOT a change in behavior for almost all SQL statements except: - ALTER TABLE t1 RENAME t2 - OPTIMIZE TABLE t1 - ANALYZE TABLE t1 - TRUNCATE TABLE t1 -- until this patch t1 or t2 could be evaluated at the first execution of prepared statement. CURRENT_DATABASE() still works OK and is evaluated at every execution of prepared statement. Note, that in stored routines this is not an issue as the default database is the database of the stored procedure and "use" statement is prohibited in stored routines. This patch makes obsolete the use of check_db_used (it was never used in the old code too) and all other places that check for table->db and assign it from THD::db if it's NULL, except the parser. How this patch was created: THD::{db,db_length} were replaced with a LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were manually checked and: - if the place uses thd->db by pointer, it was fixed to make a deep copy - if a place compared two db pointers, it was fixed to compare them by value (via strcmp/my_strcasecmp, whatever was approproate) Then this intermediate patch was used to write a smaller patch that does the same thing but without a rename. TODO in 5.1: - remove check_db_used - deploy THD::set_db in mysql_change_db See also comments to individual files.
-
ingo@mysql.com authored
Bug#17294 - INSERT DELAYED puting an \n before data Bug#16611 - INSERT DELAYED corrupts data Bug#13707 - Server crash with INSERT DELAYED on MyISAM table Combined as Bug#16218. INSERT DELAYED crashed in 5.0 on a table with a varchar that could be NULL and was created pre-5.0 (Bugs 16218 and 13707). INSERT DELAYED corrupted data in 5.0 on a table with varchar fields that was created pre-5.0 (Bugs 17294 and 16611). In case of INSERT DELAYED the open table is copied from the delayed insert thread to be able to create a record for the queue. When copying the fields, a method was used that did convert old varchar to new varchar fields and did not set up some pointers into the record buffer of the table. The field conversion was guilty for the misinterpretation of the record contents by the delayed insert thread. The wrong pointer setup was guilty for the crashes. For Bug 13707 (Server crash with INSERT DELAYED on MyISAM table) I fixed the above mentioned method to set up one of the pointers. For Bug 16218 I set up the other pointers too. But when looking at the corruptions I got aware that converting the field type was totally wrong for INSERT DELAYED. The copied table is used to create a record that is to be sent to the delayed insert thread. Of course it can interpret the record correctly only if all field types are the same in both table objects. So I revoked the fix for Bug 13707 and changed the new_field() method so that it can suppress conversions. No test case as this is a migration problem. One needs to create a table with 4.x and use it with 5.x. I added two test scripts to the bug report.
-
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.
-
- 16 Jun, 2006 1 commit
-
-
dlenev@mysql.com authored
INSERT triggers". In cases when REPLACE was internally executed via update and table had on update (on delete) triggers defined we exposed the fact that such optimization used by callng on update (not calling on delete) triggers. Such behavior contradicts our documentation which describes REPLACE as INSERT with optional DELETE. This fix just disables this optimization for tables with on delete triggers. The optimization is still applied for tables which have on update but have no on delete triggers, we just don't invoke on update triggers in this case and thus don't expose information about optimization to user. Also added test coverage for values returned by ROW_COUNT() function (and thus for values returned by mysql_affected_rows()) for various forms of INSERT.
-
- 13 Jun, 2006 1 commit
-
-
gkodinov@mysql.com authored
The INSERT DELAYED should not maintain its own private auto-increment counter, because this is assuming that other threads cannot insert into the table while the INSERT DELAYED thread is inserting, which is a wrong assumption. So the start of processing of a batch of INSERT rows in the INSERT DELAYED thread must be treated as a start of a new statement and cached next_insert_id must be cleared.
-
- 26 May, 2006 1 commit
-
-
gkodinov@mysql.com authored
The check for view security was lacking several points : 1. Check with the right set of permissions : for each table ref that participates in a view there were the right credentials to use in it's security_ctx member, but these weren't used for checking the credentials. This makes hard enforcing the SQL SECURITY DEFINER|INVOKER property consistently. 2. Because of the above the security checking for views was just ruled out in explicit ways in several places. 3. The security was checked only for the columns of the tables that are brought into the query from a view. So if there is no column reference outside of the view definition it was not detecting the lack of access to the tables in the view in SQL SECURITY INVOKER mode. The fix below tries to fix the above 3 points.
-
- 24 May, 2006 1 commit
-
-
monty@mysql.com authored
Remove dflt_field from field structure as this was only needed when createing temporary table and I found another soultion that doesn't increase the size of the field structure for all table instances. (Better fix for bug #19089) Fixed compiler warnings Fixed valgrind warning in Item_date_add_intervall::eq. (Recoding of bugfix #19490)
-
- 09 May, 2006 1 commit
-
-
dlenev@mysql.com authored
or implicitly uses stored function gives "Table not locked" error' CREATE TABLE ... SELECT ... statement which was explicitly or implicitly (through view) using stored function gave "Table not locked" error. The actual bug resides in the current locking scheme of CREATE TABLE SELECT code, which first opens and locks tables of the SELECT statement itself, and then, having SELECT tables locked, creates the .FRM, opens the .FRM and acquires lock on it. This scheme opens a possibility for a deadlock, which was present and ignored since version 3.23 or earlier. This scheme also conflicts with the invariant of the prelocking algorithm -- no table can be open and locked while there are tables locked in prelocked mode. The patch makes an exception for this invariant when doing CREATE TABLE ... SELECT, thus extending the possibility of a deadlock to the prelocked mode. We can't supply a better fix in 5.0.
-
- 05 Apr, 2006 1 commit
-
-
ingo@mysql.com authored
Additional fix for INSERT DELAYED with subselect. Originally detected in 5.1, but 5.0 could also be affected. The user thread creates a dummy table object, which is not included in the lock. The 'real' table is opened and locked by the 'delayed' system thread. The dummy object is now marked as not locked and this is tested in mysql_lock_have_duplicate().
-
- 04 Apr, 2006 1 commit
-
-
aivanov@mysql.com authored
The bug was caused by wrong behaviour of mysql_insert() which in case of INSERT DELAYED into a view exited with thd->net.report_error == 0. This blocked error reporting to the client which started waiting infinitely for response to the query.
-
- 29 Mar, 2006 1 commit
-
-
dlenev@mysql.com authored
A table with an on insert trigger was reported as crashed when the insert was processed with bulk insert mode on (handler::start_bulk_insert). The trigger was also selecting from the same table, and that caused the "crash". The same problem was present when an insert statement, which was processed in bulk mode, also used a stored function that was reading the same table. This fix disables bulk inserts if a statement uses functions or invokes triggers. Implementing more granular checks will require much more code and therefore can hardly be done in 5.0
-
- 15 Mar, 2006 1 commit
-
-
bell@book.local authored
because it can couse problem with Query cache (BUG#14767)
-
- 05 Jan, 2006 1 commit
-
-
monty@mysql.com authored
- Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
-
- 03 Jan, 2006 1 commit
-
-
serg@serg.mylan authored
-
- 20 Dec, 2005 1 commit
-
-
ingo@mysql.com authored
Problem #1: INSERT...SELECT, Version for 5.0. Extended the unique table check by a check of lock data. Merge sub-tables cannot be detected by doing name checks only.
-
- 08 Dec, 2005 1 commit
-
-
jimw@mysql.com authored
handling so that indexes are closed before trying to commit the transaction. (Bug #15536)
-
- 28 Nov, 2005 1 commit
-
-
timour@mysql.com authored
Post-review fixes according to Monty's review.
-
- 23 Nov, 2005 1 commit
-
-
konstantin@mysql.com authored
check_stack_overrun().
-
- 11 Oct, 2005 1 commit
-
-
monty@mysql.com authored
- CHAR() now returns binary string as default - CHAR(X*65536+Y*256+Z) is now equal to CHAR(X,Y,Z) independent of the character set for CHAR() - Test for both ETIMEDOUT and ETIME from pthread_cond_timedwait() (Some old systems returns ETIME and it's safer to test for both values than to try to write a wrapper for each old system) - Fixed new introduced bug in NOT BETWEEN X and X - Ensure we call commit_by_xid or rollback_by_xid for all engines, even if one engine has failed - Use octet2hex() for all conversion of string to hex - Simplify and optimize code
-