- 05 Nov, 2009 13 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 03 Nov, 2009 3 commits
-
-
Kristofer Pettersson authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
The reason for the bug is that mysqtest as well as other client tools running in test suite (mysqlbinlog, mysqldump) will first try to connect whatever database has created shared memory with default base name "MySQL" and use this. (Same effect could be seen on Unix if mtr would not care to calculate "port" and "socket" parameter). The fix ensures that all client tools and running in mtr use unique per-database shared memory base parameters, so there is no possibility to clash with already installed one. We use socket name for shared memory base (it's known to be unique). This shared-memory-base is written to the MTR config file to the [client] and [mysqld] sections. Fix made also made sure all client tools understand and correctly handle --shared-memory-base. Prior to this patch it was not the case for mysqltest, mysqlbinlog and mysql_client_test. All new connections done from mtr scripts via connect() will by default set shared-memory-base. And finally, there is a possibility to force shared memory or pipe connection and overwrite shared memory/pipe base name from within mtr scripts via optional PIPE or SHM modifier. This functionality was manually backported from 6.0 (original patch http://lists.mysql.com/commits/74749)
-
- 02 Nov, 2009 8 commits
-
-
Vladislav Vaintroub authored
Bug#31621: Windows server hanging during shutdown using named pipes and idle connection Problem: when idle pipe connection is forcefully closed with KILL statement or when the server goes down, thread that is closing connection would hang infinitely in CloseHandle(). The reason for the hang is that named pipe operations are performed synchronously. In this mode all IOs on pipe are serialized, that is CloseHandle() will not abort ReadFile() in another thread, but wait for ReadFile() to complete. The fix implements asynchrnous mode for named pipes, where operation of file are not synchronized. Read/Write operation would fire an async IO and wait for either IO completion or timeout. Note, that with this patch timeouts are properly handled for named pipes. Post-review: Win32 timeout code has been fixed for named pipes and shared memory. We do not store pointer to NET in vio structure, only the read and write timeouts. include/violite.h: Add pipe_overlapped to Vio structure for async IO for named pipes. sql-common/client.c: Use asynchronous pipe IO. sql/mysqld.cc: Use asynchronous pipe IO. vio/vio.c: -Refactor timeouts for win32 protocols: shared memory and named pipes. Store read/write timeout in VIO structure, instead of storing pointer to NET. New function vio_win32_timeout called indirectly via vio_timeout changes these values. vio/vio_priv.h: Remove vio_ignore_timeout. Add vio_win32_timeout to be used for named pipes and shared memory. vio/viosocket.c: Use async IO for named pipes. After issuing IO, wait for either IO completion, pipe_close_event or timeout. Refactor timeouts for named pipe and shared memory.
-
Davi Arnaut authored
-
Davi Arnaut authored
Backport a ndb patch: fix bug with crash during restart, where a mbyte incorrectly could be skipped, leading to "end of log wo/ finding gci".
-
Luis Soares authored
-
Luis Soares authored
-
Martin Hansson authored
When a query was using a DATE or DATETIME value formatted using any other separator characters beside hyphen '-', a query with a greater-or-equal '>=' condition matching only the greatest value in an indexed column, the result was empty if index range scan was employed. The range optimizer got a new feature between 5.1.38 and 5.1.39 that changes a greater-or-equal condition to a greater-than if the value matching that in the query was not present in the table. But the value comparison function compared the dates as strings instead of dates. The bug was fixed by splitting the function get_date_from_str in two: One part that parses and does error checking. This function is now visible outside the module. The old get_date_from_str now calls the new function. mysql-test/r/range.result: Bug#47925: Test result mysql-test/t/range.test: Bug#47925: Test case sql/item.cc: Bug#47925: Fix + some edit on the comments sql/item.h: Bug#47925: Changed function signature sql/item_cmpfunc.cc: Bug#47925: Split function in two sql/item_cmpfunc.h: Bug#47925: Declaration of new function sql/opt_range.cc: Bug#47925: Added THD to function call sql/time.cc: Bug#47925: Added microsecond comparison
-
Davi Arnaut authored
-
Tatiana A. Nurnberg authored
-
- 01 Nov, 2009 1 commit
-
-
Luis Soares authored
Conflicts ========= Text conflict in sql/sql_class.cc 1 conflicts encountered.
-
- 31 Oct, 2009 2 commits
-
-
Sergey Vojtovich authored
-
Alexander Nozdrin authored
-
- 30 Oct, 2009 12 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
with temporary tables There were two problems the test case from this bug was triggering: 1. JOIN::rollup_init() was supposed to wrap all constant Items into another object for queries with the WITH ROLLUP modifier to ensure they are never considered as constants and therefore are written into temporary tables if the optimizer chooses to employ them for DISTINCT/GROUP BY handling. However, JOIN::rollup_init() was called before make_join_statistics(), so Items corresponding to fields in const tables could not be handled as intended, which was causing all kinds of problems later in the query execution. In particular, create_tmp_table() assumed all constant items except "hidden" ones to be removed earlier by remove_const() which led to improperly initialized Field objects for the temporary table being created. This is what was causing crashes and valgrind errors in storage engines. 2. Even when the above problem had been fixed, the query from the test case produced incorrect results due to some DISTINCT/GROUP BY optimizations being performed by the optimizer that are inapplicable in the WITH ROLLUP case. Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations when the WITH ROLLUP modifier is present, and splitting the const-wrapping part of JOIN::rollup_init() into a separate method which is now invoked after make_join_statistics() when the const tables are already known. mysql-test/r/olap.result: Added a test case for bug #48131. mysql-test/t/olap.test: Added a test case for bug #48131. sql/sql_select.cc: 1. Disabled inapplicable DISTINCT/GROUP BY optimizations when the WITH ROLLUP modifier is present. 2. Split the const-wrapping part of JOIN::rollup_init() into a separate method. sql/sql_select.h: Added rollup_process_const_fields() declaration.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
subquery returning multiple rows Error handling was missing when handling subqueires in WHERE and when assigning a SELECT result to a @variable. This caused crash(es). Fixed by adding error handling code to both the WHERE condition evaluation and to assignment to an @variable.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
having clause... The fix for bug 46184 was not very complete. It was not covering views using temporary tables and multiple tables in a FROM clause. Fixed by reverting the fix for 46184 and making a more general check that is checking at the right execution stage and for all of the non-supported cases. Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden. Updated the analyse.test and subselect.test accordingly.
-
Georgi Kodinov authored
-
- 29 Oct, 2009 1 commit
-
-
Tatiana A. Nurnberg authored
If an outer query is broken, a subquery might not even get set up. EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all of the half-setup info. We now catch this case and print as much as we have, as it doesn't cost us anything (doesn't make regular execution slower). mysql-test/r/explain.result: Show that EXPLAIN EXTENDED with subquery and illegal out query doesn't crash. Show also that SHOW WARNINGS will render an additional Note in the hope of being, well, helpful. mysql-test/t/explain.test: If we have only half a query for EXPLAIN EXTENDED to print (i.e., incomplete subquery info as outer query is illegal), we should provide the user with as much info as we easily can if they ask for it. What we should not do is crash when they come asking for help, that violates etiquette in some countries. sql/item_subselect.cc: If the sub-query's actually set up, print it. Otherwise, elide.
-