- 26 Feb, 2008 5 commits
-
-
davi@mysql.com/endora.local authored
Bug#34678 @@debug variable's incremental mode The problem is that the per-thread debugging settings stack wasn't being deallocated before the thread termination, leaking the stack memory. The chosen solution is to push a new state if the current is set to the initial settings and pop it (free) once the thread finishes.
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
-
kostja@dipika.(none) authored
(Test for Bug#32265)
-
- 25 Feb, 2008 1 commit
-
-
davi@mysql.com/endora.local authored
The problem is that the commands COM_STMT_CLOSE, COM_STMT_RESET, COM_STMT_SEND_LONG_DATA weren't being logged to the general log. The solution is to log the general log the aforementioned commands.
-
- 22 Feb, 2008 15 commits
-
-
andrey@whirlpool.hristov.com authored
into whirlpool.hristov.com:/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
-
andrey@whirlpool.hristov.com authored
--local-infile=0 checks can be bypassed by sending a FETCH LOCAL FILE response Add a check for CLIENT_LOCAL_FILES before sending a local file. Beware, that all binary distributions enable sending of local files and it's up to the programs which use libmysql to disable it, if they don't use this functionality. Otherwise they are not safe.
-
andrey@whirlpool.hristov.com authored
into whirlpool.hristov.com:/work/mysql-5.1-runtime
-
andrey@whirlpool.hristov.com authored
Disabled events weren't removed from the memory queue after the scheduler has been re-enabled. After recalculation of next execution time of an event, it might get disabled.
-
kostja@dipika.(none) authored
-
kostja@dipika.(none) authored
-
davi@buzz.(none) authored
-
davi@buzz.(none) authored
into buzz.(none):/home/davi/mysql-5.1-runtime
-
davi@buzz.(none) authored
concurrent inserts.
-
anozdrin/alik@quad. authored
into quad.:/mnt/raid/alik/MySQL/devel/bug-30217/5.1-rt-bug30217
-
anozdrin/alik@quad. authored
between 5.0 and 5.1. The problem was that in the patch for Bug#11986 it was decided to store original query in UTF8 encoding for the INFORMATION_SCHEMA. This approach however turned out to be quite difficult to implement properly. The main problem is to preserve the same IS-output after dump/restore. So, the fix is to rollback to the previous functionality, but also to fix it to support multi-character-set-queries properly. The idea is to generate INFORMATION_SCHEMA-query from the item-tree after parsing view declaration. The IS-query should: - be completely in UTF8; - not contain character set introducers. For more information, see WL4052.
-
davi@buzz.(none) authored
-
davi@buzz.(none) authored
into buzz.(none):/home/davi/mysql-5.1-runtime
-
- 21 Feb, 2008 9 commits
-
-
davi@buzz.(none) authored
-
davi@mysql.com/endora.local authored
The problem is that CREATE VIEW statements inside prepared statements weren't being expanded during the prepare phase, which leads to objects not being allocated in the appropriate memory arenas. The solution is to perform the validation of CREATE VIEW statements during the prepare phase of a prepared statement. The validation during the prepare phase assures that transformations of the parsed tree will use the permanent arena of the prepared statement.
-
anozdrin/alik@quad. authored
sending SIGHUP. There were two problems: - after some recent fix, the server started to crash after receiving SIGHUP. That happened because LEX of new THD-object was not properly initialized. - user-specified log options were ignored when logs were reopened. The fix is to 1) initialize LEX and 2) take user-specified options into account. There is no test case in this CS, because our test suite does not support sending SIGHUP to the server.
-
anozdrin/alik@quad. authored
-
anozdrin/alik@quad. authored
into quad.:/mnt/raid/alik/MySQL/devel/bug-34337/5.1-rt-bug34337
-
anozdrin/alik@quad. authored
a table name. The problem was that fill_defined_view_parts() did not return an error if a table is going to be altered. That happened if the table was already in the table cache. In that case, open_table() returned non-NULL value (valid TABLE-instance from the cache). The fix is to ensure that an error is thrown even if the table is in the cache. (This is a backport of the original patch for 5.1)
-
davi@buzz.(none) authored
-
davi@buzz.(none) authored
into buzz.(none):/home/davi/mysql-5.1-runtime
-
davi@mysql.com/endora.local authored
by patch for bug 32265 .
-
- 20 Feb, 2008 5 commits
-
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@mysql.com/endora.local authored
The problem is that when a stored procedure is being parsed for the first execution, the body is copied to a temporary buffer which is disregarded sometime after the statement is parsed. And during this parsing phase, the rule for CREATE VIEW was holding a reference to the string being parsed for use during the execution of the CREATE VIEW statement, leading to invalid memory access later. The solution is to allocate and copy the SELECT of a CREATE VIEW statement using the thread memory root, which is set to the permanent arena of the stored procedure.
-
davi@mysql.com/endora.local authored
Executing a prepared statement associated with a materialized cursor yields to the client a metadata packet with wrong table and database names. The problem was occurring because the server was sending the the name of the temporary table used by the cursor instead of the table name of the original table. The same problem occurs when selecting from views, in which case the table name was being sent and not the name of the view. The solution is to fill the list item from the temporary table but preserving the table and database names of the original fields. This is achieved by tweaking the Select_materialize to accept a pointer to the Materialized_cursor class which contains the item list to be filled.
-
anozdrin/alik@quad. authored
a table name. The problem was that fill_defined_view_parts() did not return an error if a table is going to be altered. That happened if the table was already in the table cache. In that case, open_table() returned non-NULL value (valid TABLE-instance from the cache). The fix is to ensure that an error is thrown even if the table is in the cache.
-
- 19 Feb, 2008 5 commits
-
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
kostja@dipika.(none) authored
-