summaryrefslogtreecommitdiff
path: root/sql
Commit message (Collapse)AuthorAgeFilesLines
* Added more wait states for THD wait serviceMikael Ronstrom2010-10-274-1/+25
|
* Auto-merge from mysql-5.5-merge.Alexander Nozdrin2010-09-2821-113/+438
|\
| * Fix compile warning about passing NULL to non-pointerDmitry Lenev2010-09-241-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | argument of inline_mysql_mutex_init in sql_base.cc. When initializing LOCK_dd_owns_lock_open mutex pass correct PSI key instead of NULL value. mysql-test/suite/perfschema/r/dml_setup_instruments.result: Updated test results after adding P_S instrumentation for LOCK_dd_owns_lock_open. sql/sql_base.cc: When initializing LOCK_dd_owns_lock_open mutex pass correct PSI key instead of NULL value.
| * Merge 5.5 -> 5.5-merge.Konstantin Osipov2010-09-2410-32/+122
| |\
| | * Automerge (most) changes of the 5.5.6-rc release build to main 5.5.Joerg Bruehe2010-09-1010-32/+122
| | |\ | | | | | | | | | | | | | | | | This is not the final merge!
| | | * A temporary workaround for bug #56405 "Deadlock in theDmitry Lenev2010-09-065-11/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDL deadlock detector". Deadlock could have occurred when workload containing mix of DML, DDL and FLUSH TABLES statements affecting same set of tables was executed in heavily concurrent environment. This deadlock occurred when several connections tried to perform deadlock detection in metadata locking subsystem. The first connection started traversing wait-for graph, encountered sub-graph representing wait for flush, acquired LOCK_open and dived into sub-graph inspection. When it has encounterd sub-graph corresponding to wait for metadata lock and blocked while trying to acquire rd-lock on MDL_lock::m_rwlock (*) protecting this subgraph, since some other thread had wr-lock on it. When this wr-lock was released it could have happened (if there was other pending wr-lock against this rwlock) that rd-lock from the first connection was left unsatisfied but at the same time new rd-lock request from the second connection sneaked in and was satisfied (for this to be possible second rd- request should come exactly after wr-lock is released but before pending wr-lock manages to grab rwlock, which is possible both on Linux and in our own rwlock implementation). If this second connection continued traversing wait-for graph and encountered sub-graph representing wait for flush it tried to acquire LOCK_open and thus deadlock was created. This patch tries to workaround this problem but not allowing deadlock detector to lock LOCK_open mutex if some other thread doing deadlock detection already owns it and current search depth is greater than 0. Instead deadlock is reported. Other possible solutions are either known to have negative effects on performance or require much more time for proper implementation and testing. No test case is provided as this bug is very hard to repeat in MTR environment but is repeatable with the help of RQG tests. sql/mdl.cc: Moved Deadlock_detection_visitor::m_current_search_depth to parent class to make it available in TABLE_SHARE::visit_subgraph(). Added MDL_wait_for_graph_visitor::abort_traversal() method which allows to abort traversal of a wait-for graph and report a deadlock. sql/mdl.h: Moved Deadlock_detection_visitor::m_current_search_depth to parent class to make it available in TABLE_SHARE::visit_subgraph(). Added MDL_wait_for_graph_visitor::abort_traversal() method which allows to abort traversal of a wait-for graph and report a deadlock. sql/sql_base.cc: Added dd_owns_lock_open counter and mutex protecting it to track number of connections which do deadlock detection and own or try to acquire LOCK_open. sql/sql_base.h: Added dd_owns_lock_open counter and mutex protecting it to track number of connections which do deadlock detection and own or try to acquire LOCK_open. sql/table.cc: Workaround bug #56405 but not allowing MDL deadlock detector to lock LOCK_open mutex if some other thread doing deadlock detection already owns it and current search depth is greater than 0. Instead report deadlock.
| | | * Cherry-picking patch for Bug#56137 from mysql-5.5-runtime.Alexander Nozdrin2010-08-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------ revno: 3124 revision-id: dlenev@mysql.com-20100831090419-rzr5ktekby2gspm1 parent: alik@sun.com-20100827083901-x4wvtc10u9p7gcs9 committer: Dmitry Lenev <dlenev@mysql.com> branch nick: mysql-5.5-rt-56137 timestamp: Tue 2010-08-31 13:04:19 +0400 message: Bug #56137 "Assertion `thd->lock == 0' failed on upgrading from 5.1.50 to 5.5.6". Debug builds of the server aborted due to an assertion failure when DROP DATABASE statement was run on an installation which had outdated or corrupt mysql.proc table. Particularly this affected the mysql_upgrade tool which is run as part of 5.1 to 5.5 upgrade. The problem was that sp_drop_db_routines(), which was invoked during dropping of the database, could have returned without closing and unlocking mysql.proc table in cases when this table was not up-to-date with the current server. As a result further attempt to open and lock the mysql.event table, which was necessary to complete dropping of the database, ended up with an assert. This patch solves this problem by ensuring that sp_drop_db_routines() always closes mysql.proc table and releases metadata locks on it. This is achieved by changing open_proc_table_for_update() function to close tables and release metadata locks acquired by it in case of failure. This step also makes behavior of the latter function consistent with behavior of open_proc_table_for_read()/ open_and_lock_tables(). Test case for this bug was added to sp-destruct.test. ------------------------------------------------------------
| | | * Cherry-pick patch for Bug#56120 from mysql-5.5-bugfixing.Alexander Nozdrin2010-08-311-2/+7
| | | |
| | | * Bug#56387 Create initial database in the proper locationDaniel Fischer2010-08-311-2/+1
| | | |
| | | * Bug#55077: Assertion failed: width > 0 && to != ((void *)0),Alexey Kopytov2010-08-253-19/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | file .\dtoa.c The assertion failure was correct because the 'width' argument of my_gcvt() has the signed integer type, whereas the unsigned value UINT_MAX32 was being passed by the caller (Field_double::val_str()) leading to a negative width in my_gcvt(). The following chain of problems was found by further analysis: 1. The display width for a floating point number is calculated in Field_double::val_str() as either field_length or the maximum possible length of string representation of a floating point number, whichever is greater. Since in the bug's test case field_length is UINT_MAX32, we get the same value as the display width. This does not make any sense because for numeric values field_length only matters for ZEROFILL columns, otherwise it does not make sense to allocate that much memory just to print a number. Field_float::val_str() has a similar problem. 2. Even if the above wasn't the case, we would still get a crash on a slightly different test case when trying to allocate UINT_MAX32 bytes with String::alloc() because the latter does not handle such large input values correctly due to alignment overflows. 3. Even when String::alloc() is fixed to return an error when an alignment overflow occurs, there is still a problem because almost no callers check its return value, and Field_double::val_str() is not an exception (same for Field_float::val_str()). 4. Even if all of the above wasn't the case, creating a Field_double object with UINT_MAX32 as its field_length does not make much sense either, since the .frm code limits it to MAX_FIELD_CHARLENGTH (255) bytes. Such a beast can only be created by create_tmp_field_from_item() from an Item with REAL_RESULT as its result_type() and UINT_MAX32 as its max_length. 5. For the bug's test case, the above condition (REAL_RESULT Item with max_length = UINT_MAX32) was a result of Item_func_if::fix_length_and_dec() "shortcutting" aggregation of argument types when one of the arguments was a constant NULL. In this case, the attributes of the aggregated type were simply copied from the other, non-NULL argument, but max_length was still calculated as per the general, non-shortcut case, by choosing the greatest of argument's max_length, which is obviously not correct. The patch addresses all of the above problems, even though fixing the assertion failure for the particular test case would require only a subset of the above problems to be solved. client/sql_string.cc: Return an error in case of uint32 overflow in alignment. Also assert there was no overflow to help find such conditions in debug builds, since almost no callers check the return value of String::alloc(). mysql-test/r/func_if.result: Add a test case for bug #55077. mysql-test/t/func_if.test: Add a test case for bug #55077. sql/field.cc: - Assert we don't operate with fields wider than 255 (MAX_FIELD_CHARLENGTH) bytes in both Field_float and Field_double. - Don't take field_length into account when calculating the output buffer length. - Check the return value of String::alloc() sql/item_cmpfunc.cc: When shortcutting type aggregation, don't take the NULL argument's max_length into account. sql/sql_string.cc: Return an error in case of uint32 overflow in alignment. Also assert there was no overflow to help find such conditions in debug builds, since almost no callers check the return value of String::alloc().
| * | | Merged changes from 5.1-bugteam for bug#42503.Dmitry Shulga2010-09-241-0/+2
| |\ \ \
| | * | | Follow-up for Bug#42503: fix a compilation warning.Dmitry Shulga2010-09-241-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | sql/sql_cache.cc: Added include of send_data_in_chunks() definiton when macros EMBEDDED_LIBRARY is on.
| * | | | Auto-merge from mysql-5.1-bugteam for bug#56821.Dmitry Shulga2010-09-221-16/+30
| |\ \ \ \ | | |/ / /
| | * | | Fixed bug#56821 - failure to start the MySQL Service.Dmitry Shulga2010-09-221-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sql/log.cc: reopen_fstreams modified: fixed error in processing of stdout/stderr when run mysqld as Windows service.
| | * | | Bug#46339 - crash on REPAIR TABLE merge table USE_FRMIngo Struewing2010-09-211-3/+0
| | |\ \ \ | | | | | | | | | | | | | | | | | | Merge from saved bundle.
| | | * | | Bug#46339 - crash on REPAIR TABLE merge table USE_FRMIngo Struewing2010-04-261-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REPAIR TABLE ... USE_FRM crashed debug servers. A wrong assert assumed that this operation would not be executed for MERGE tables. Removed the assert. mysql-test/r/merge.result: Bug#46339 - crash on REPAIR TABLE merge table USE_FRM Added test result. mysql-test/t/merge.test: Bug#46339 - crash on REPAIR TABLE merge table USE_FRM Added test. sql/sql_table.cc: Bug#46339 - crash on REPAIR TABLE merge table USE_FRM Removed false assert.
| * | | | | merge mysql-5.1-bugteam --> mysql-5.5-mergeAlfranio Correia2010-09-171-2/+6
| |\ \ \ \ \ | | |/ / / /
| | * | | | merge mysql-5.1-bugteam (local) --> mysql-5.1-bugteamAlfranio Correia2010-09-171-2/+6
| | |\ \ \ \
| | | * | | | BUG#55961 Savepoint Identifier should be enclosed with backticksAlfranio Correia2010-09-021-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Added backticks to the savepoint identifier.
| * | | | | | 5.1-bugteam->5.5-mergeSergey Glukhov2010-09-161-3/+8
| |\ \ \ \ \ \ | | |/ / / / /
| | * | | | | Bug#50402 Optimizer producing wrong results when using Index Merge on InnoDB Sergey Glukhov2010-09-161-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subselect executes twice, at JOIN::optimize stage and at JOIN::execute stage. At optimize stage Innodb prebuilt struct which is used for the retrieval of column values is initialized in. ha_innobase::index_read(), prebuilt->sql_stat_start is true. After QUICK_ROR_INTERSECT_SELECT finished his job it restores read_set/write_set bitmaps with initial values and deactivates one of the handlers used by QUICK_ROR_INTERSECT_SELECT in JOIN::cleanup (it's the case when we reuse original handler as one of handlers required by QUICK_ROR_INTERSECT_SELECT object). On second subselect execution inactive handler is activated in QUICK_RANGE_SELECT::reset, file->ha_index_init(). In ha_index_init Innodb prebuilt struct is reinitialized with inappropriate read_set/write_set bitmaps. Further reinitialization in ha_innobase::index_read() does not happen as prebuilt->sql_stat_start is false. It leads to partial retrieval of required field values and we get a mix of field values from different records in the record buffer. The fix is to reset read_set/write_set bitmaps as these values are required for proper intialization of internal InnoDB struct which is used for the retrieval of column values (see build_template(), ha_innodb.cc) mysql-test/include/index_merge_ror_cpk.inc: test case mysql-test/r/index_merge_innodb.result: test case mysql-test/r/index_merge_myisam.result: test case sql/opt_range.cc: if ROR merge scan is used we need to reset read_set/write_set bitmaps as these values are required for proper intialization of internal InnoDB struct which is used for the retrieval of column values (see build_template(), ha_innodb.cc)
| * | | | | | Merge from 5.1-bugteamMagne Mahre2010-09-161-0/+1
| |\ \ \ \ \ \ | | |/ / / / /
| | * | | | | Bug #54606 innodb fast alter table + pack_keys=0 prevents Magne Mahre2010-09-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | adding new indexes A fast alter table requires that the existing (old) table and indices are unchanged (i.e only new indices can be added). To verify this, the layout and flags of the old table/indices are compared for equality with the new. The PACK_KEYS option is a no-op in InnoDB, but the flag exists, and is used in the table compare. We need to check this (table) option flag before deciding whether an index should be packed or not. If the table has explicitly set PACK_KEYS to 0, the created indices should not be marked as packed/packable.
| * | | | | | Auto-merge from mysql-5.1-bugteam for bug#42503.Dmitry Shulga2010-09-162-6/+65
| |\ \ \ \ \ \ | | |/ / / / /
| | * | | | | Fixed bug#42503 - "Lost connection" errors when usingDmitry Shulga2010-09-162-6/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compression protocol. The loss of connection was caused by a malformed packet sent by the server in case when query cache was in use. When storing data in the query cache, the query cache memory allocation algorithm had a tendency to reduce the amount of memory block necessary to store a result set, up to finally storing the entire result set in a single block. With a significant result set, this memory block could turn out to be quite large - 30, 40 MB and on. When such a result set was sent to the client, the entire memory block was compressed and written to network as a single network packet. However, the length of the network packet is limited by 0xFFFFFF (16MB), since the packet format only allows 3 bytes for packet length. As a result, a malformed, overly large packet with truncated length would be sent to the client and break the client/server protocol. The solution is, when sending result sets from the query cache, to ensure that the data is chopped into network packets of size <= 16MB, so that there is no corruption of packet length. This solution, however, has a shortcoming: since the result set is still stored in the query cache as a single block, at the time of sending, we've lost boundaries of individual logical packets (one logical packet = one row of the result set) and thus can end up sending a truncated logical packet in a compressed network packet. As a result, on the client we may require more memory than max_allowed_packet to keep, both, the truncated last logical packet, and the compressed next packet. This never (or in practice never) happens without compression, since without compression it's very unlikely that a) a truncated logical packet would remain on the client when it's time to read the next packet b) a subsequent logical packet that is being read would be so large that size-of-new-packet + size-of-old-packet-tail > max_allowed_packet. To remedy this issue, we send data in 1MB sized packets, that's below the current client default of 16MB for max_allowed_packet, but large enough to ensure there is no unnecessary overhead from too many syscalls per result set. sql/net_serv.cc: net_realloc() modified: consider already used memory when compare packet buffer length sql/sql_cache.cc: modified Query_cache::send_result_to_client: send result to client in chunks limited by 1 megabyte.
| | * | | | | mergeMattias Jonsson2010-09-131-0/+9
| | |\ \ \ \ \
| * | \ \ \ \ \ mergeMattias Jonsson2010-09-133-16/+65
| |\ \ \ \ \ \ \ | | |/ / / / / /
| | * | | | | | mergeMattias Jonsson2010-09-133-16/+65
| | |\ \ \ \ \ \
| | | * \ \ \ \ \ mergeMattias Jonsson2010-09-102-15/+56
| | | |\ \ \ \ \ \
| | | | * | | | | | Bug#55458: Partitioned MyISAM table gets crashed by multi-table updateMattias Jonsson2010-09-072-12/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updated according to reviewers comments.
| | | | * | | | | | Bug#55458: Partitioned MyISAM table gets crashed by multi-table updateMattias Jonsson2010-08-102-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that the handler call ::extra(HA_EXTRA_CACHE) was cached but the ::extra(HA_EXTRA_PREPARE_FOR_UPDATE) was not. Solution was to also cache the other call and forward it when moving to a new partition to scan. mysql-test/r/partition.result: test result mysql-test/t/partition.test: New test from bug report. sql/ha_partition.cc: cache the HA_EXTRA_PREPARE_FOR_UPDATE just like HA_EXTRA_CACHE. sql/ha_partition.h: Added cache flag for HA_EXTRA_PREPARE_FOR_UPDATE
| | | * | | | | | | mergeMattias Jonsson2010-09-101-1/+9
| | | |\ \ \ \ \ \ \
| | | | * | | | | | | Bug#53806: Wrong estimates for range query in partitioned MyISAM tableMattias Jonsson2010-08-261-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug#46754: 'rows' field doesn't reflect partition pruning The EXPLAIN's result in 'rows' field was evaluated to number of rows when the table was opened (not from the table cache) and only the partitions left after pruning was updated with its correct number of rows. The evaluation of the 'rows' field was using handler::records() which is a potentially expensive call, and ignores the partitioning pruning. The fix was to use the handlers stats.records after updating it with ::info(HA_STATUS_VARIABLE) instead. mysql-test/r/partition_pruning.result: updated result mysql-test/t/partition_pruning.test: Added test. sql/sql_select.cc: Use ::info + stats.records instead of ::records().
| * | | | | | | | | | Merge of fix for Bug#50394.Martin Hansson2010-09-131-0/+9
| |\ \ \ \ \ \ \ \ \ \ | | | |_|_|_|/ / / / / | | |/| | | | | | | |
| | * | | | | | | | | Bug #50394: Regression in EXPLAIN with index scan, LIMIT, GROUP BY andMartin Hansson2010-09-131-0/+9
| | |/ / / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ORDER BY computed col GROUP BY implies ORDER BY in the MySQL dialect of SQL. Therefore, when an index on the first table in the query is used, and that index satisfies ordering according to the GROUP BY clause, the query optimizer estimates the number of tuples that need to be read from this index. If there is a LIMIT clause, table statistics on tables following this 'sort table' are employed. There may be a separate ORDER BY clause however, which mandates reading the whole 'sort table' anyway. But the previous estimate was left untouched. Fixed by removing the estimate from EXPLAIN output if GROUP BY is used in conjunction with an ORDER BY clause that mandates using a temporary table.
| * | | | | | | | | manual merge 5.1-bugteam --> 5.5-merge (bug 55779)Gleb Shchepa2010-09-131-2/+4
| |\ \ \ \ \ \ \ \ \ | | |/ / / / / / / /
| | * | | | | | | | Bug #55779: select does not work properly in mysql serverGleb Shchepa2010-09-131-2/+4
| | |/ / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Version "5.1.42 SUSE MySQL RPM" When a query was using a DATE or DATETIME value formatted using different formatting than "yyyy-mm-dd HH:MM:SS", a query with a greater-or-equal '>=' condition matched only greater values in an indexed TIMESTAMP column. The problem was introduced by the fix for the bug 46362 and partially solved (for DATE and DATETIME columns only) by the fix for the bug 47925. The stored_field_cmp_to_item function has been modified to take into account TIMESTAMP columns like we do for DATE and DATETIME columns. mysql-test/r/type_timestamp.result: Test case for bug #55779. mysql-test/t/type_timestamp.test: Test case for bug #55779. sql/item.cc: Bug #55779: select does not work properly in mysql server Version "5.1.42 SUSE MySQL RPM" The stored_field_cmp_to_item function has been modified to take into account TIMESTAMP columns like we do for DATE and DATETIME.
| * | | | | | | | Manual merge of the fix for bug #54190 and the addendum patchAlexey Kopytov2010-09-093-2/+15
| |\ \ \ \ \ \ \ \ | | |/ / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to 5.5 (removed one test case as it is no longer valid). mysql-test/r/select.result: Removed a part of the test case for bug#48291 since it is not valid anymore. The comments for the removed part were actually describing a side-effect from the problem addressed by the addendum patch for bug #54190. mysql-test/t/select.test: Removed a part of the test case for bug#48291 since it is not valid anymore. The comments for the removed part were actually describing a side-effect from the problem addressed by the addendum patch for bug #54190.
| | * | | | | | | Addendum patch for bug #54190.Alexey Kopytov2010-09-091-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch caused some test failures when merged to 5.5 because, unlike 5.1, it utilizes Item_cache_row to actually cache row values. The problem was that Item_cache_row::bring_value() essentially did nothing. In particular, it did not update its null_value, so all Item_cache_row objects were always having their null_values set to TRUE. This went unnoticed previously, but now when Arg_comparator::compare_row() actually depends on the row's null_value to evaluate the comparison, the problem has surfaced. Fixed by calling the underlying item's bring_value() and updating null_value in Item_cache_row::bring_value(). Since the problem also exists in 5.1 code (albeit hidden, since the relevant code is not used anywhere), the addendum patch is against 5.1.
| | * | | | | | | Automerge.Alexey Kopytov2010-09-092-1/+11
| | |\ \ \ \ \ \ \
| | | * | | | | | | Bug #54190: Comparison to row subquery produces incorrectAlexey Kopytov2010-09-092-1/+11
| | | | |_|/ / / / | | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | result Row subqueries producing no rows were not handled as UNKNOWN values in row comparison expressions. That was a result of the following two problems: 1. Item_singlerow_subselect did not mark the resulting row value as NULL/UNKNOWN when no rows were produced. 2. Arg_comparator::compare_row() did not take into account that a whole argument may be NULL rather than just individual scalar values. Before bug#34384 was fixed, the above problems were hidden because an uninitialized (i.e. without any stored value) cached object would appear as NULL for scalar values in a row subquery returning an empty result. After the fix Arg_comparator::compare_row() would try to evaluate uninitialized cached objects. Fixed by removing the aforementioned problems. mysql-test/r/row.result: Added a test case for bug #54190. mysql-test/r/subselect.result: Updated the result for a test relying on wrong behavior. mysql-test/t/row.test: Added a test case for bug #54190. sql/item_cmpfunc.cc: If either of the argument rows is NULL, return NULL as the result of comparison. sql/item_subselect.cc: Adjust null_value for Item_singlerow_subselect depending on whether a row has been produced by the row subquery.
| * | | | | | | | Merge of fix for Bug#51070.Martin Hansson2010-09-072-32/+95
| |\ \ \ \ \ \ \ \ | | |/ / / / / / /
| | * | | | | | | Bug#51070: Query with a NOT IN subquery predicate returns a wrong result setMartin Hansson2010-09-072-32/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EXISTS transformation has additional switches to catch the known corner cases that appear when transforming an IN predicate into EXISTS. Guarded conditions are used which are deactivated when a NULL value is seen in the outer expression's row. When the inner query block supplies NULL values, however, they are filtered out because no distinction is made between the guarded conditions; guarded NOT x IS NULL conditions in the HAVING clause that filter out NULL values cannot be de-activated in isolation from those that match values or from the outer expression or NULL's. The above problem is handled by making the guarded conditions remember whether they have rejected a NULL value or not, and index access methods are taking this into account as well. The bug consisted of 1) Not resetting the property for every nested loop iteration on the inner query's result. 2) Not propagating the NULL result properly from inner query to IN optimizer. 3) A hack that may or may not have been needed at some point. According to a comment it was aimed to fix #2 by returning NULL when FALSE was actually the result. This caused failures when #2 was properly fixed. The hack is now removed. The fix resolves all three points.
| * | | | | | | | Auto-merge from mysql-5.1-bugteam.Dmitry Shulga2010-09-071-0/+9
| |\ \ \ \ \ \ \ \ | | |/ / / / / / /
| | * | | | | | | Fixed bug #55421 - Protocol::end_statement(): Assertion `0' onDmitry Shulga2010-09-071-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | multi-table UPDATE IGNORE. The problem was that if there was an active SELECT statement during trigger execution, an error risen during the execution may cause a crash. The fix is to temporary reset LEX::current_select before trigger execution and restore it afterwards. This way errors risen during the trigger execution are processed as if there was no active SELECT. mysql-test/r/trigger_notembedded.result: added test case result for bug #55421. mysql-test/t/trigger_notembedded.test: added test case for bug #55421. sql/sql_trigger.cc: Reset thd->lex->current_select before start trigger execution and restore its original value after execution is finished. This is neccessery in order to set error status in diagnostic_area in case of trigger execution failure.
| | * | | | | | | Bug#54543: update ignore with incorrect subquery leads to assertion failure:Martin Hansson2010-09-071-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | inited==INDEX When an error occurs while sending the data in a temporary table there was no cleanup performed. This caused a failed assertion in the case when different access methods were used for populating the table vs. retrieving the data from the table if IGNORE was specified and sql_safe_updates = 0. In this case execution continues, but the handler expects to continue with the access method used for row retrieval. Fixed by doing the cleanup even if errors occur.
| | * | | | | | | Bug#39932 "create table fails if column for FK is in differentMagne Mahre2010-09-011-1/+3
| | |/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | case than in corr index". Server was unable to find existing or explicitly created supporting index for foreign key if corresponding statement clause used field names in case different than one used in key specification and created yet another supporting index. In cases when name of constraint (and thus name of generated index) was the same as name of existing/explicitly created index this led to duplicate key name error. The problem was that unlike all other code Key_part_spec::operator==() compared field names in case sensitive fashion. As result routines responsible for getting rid of redundant generated supporting indexes for foreign key were not working properly for versions of field names using different cases. (backported from mysql-trunk) sql/sql_class.cc: Make field name comparison case-insensitive like it is in the rest of server.
| | * | | | | | automerge local --> 5.1-bugteam (bug 53034)Gleb Shchepa2010-08-311-1/+17
| | |\ \ \ \ \ \
| * | \ \ \ \ \ \ Automerge.Ramil Kalimullin2010-09-061-2/+4
| |\ \ \ \ \ \ \ \ | | |/ / / / / / / | | | | | | | / / | | |_|_|_|_|/ / | |/| | | | | |
| | * | | | | | Automerge.Ramil Kalimullin2010-08-302-21/+0
| | |\ \ \ \ \ \