- 22 Oct, 2007 1 commit
-
-
anozdrin/alik@station. authored
A deprecation warning added.
-
- 20 Oct, 2007 1 commit
-
-
anozdrin/alik@station. authored
Assertion `table->key_read == 0' failed. The problem was that key_read on a table in a sub-select was not properly reset. That happens because the code responsible for that is copy&pasted all around the server. In some place, it was obviously forgotten to be pasted. The fix is to reset key_read properly.
-
- 19 Oct, 2007 5 commits
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
Add comments.
-
anozdrin/alik@station. authored
There actually were several problems here: - WRITE-lock is required to load events from the mysql.event table, but in the read-only mode an ordinary user can not acquire it; - Security_context::master_access attribute was not properly initialized in Security_context::init(), which led to differences in behavior with and without debug configure options. - if the server failed to load events from mysql.event, it forgot to close the mysql.event table, that led to the coredump, described in the bug report. The patch is to fix all these problems: - Use the super-user to acquire WRITE-lock on the mysql.even table; - The WRITE-lock is acquired by the event scheduler in two cases: - on initial loading of events from the database; - when an event has been executed, so its attributes should be updated. Other cases when WRITE-lock is needed for the mysql.event table happen under the user account. So, nothing should be changed there for the read-only mode. The user is able to create/update/drop an event only if he is a super-user. - Initialize Security_context::master_access; - Close the mysql.event table in case something went wrong.
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-runtime
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge
-
- 18 Oct, 2007 6 commits
-
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge
-
davi@moksha.com.br authored
into moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime
-
davi@moksha.com.br authored
-
davi@moksha.com.br authored
into moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime
-
davi@moksha.com.br authored
The general log write function (general_log_print) uses printf style arguments which need to be pre-processed, meaning that the all arguments are copied to a single buffer and the problem is that the buffer size is constant (1022 characters) but queries can be much larger then this. The solution is to introduce a new log write function that accepts a buffer and it's length as arguments. The function is to be used when a formatted output is not required, which is the case for almost all query write-to-log calls. This is a incompatible change with respect to the log format of prepared statements.
-
- 17 Oct, 2007 13 commits
-
-
dkatz@damien-katzs-computer.local authored
into damien-katzs-computer.local:/Users/dkatz/mysql-5.1-runtime
-
dkatz@damien-katzs-computer.local authored
Previously, UDF *_init functions were passed constant strings with erroneous lengths. The length came from the containing variable's size, not the length of the value itself. Now the *_init functions get the constant as a null terminated string with the correct length supplied too.
-
davi@moksha.com.br authored
into moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime
-
davi@moksha.com.br authored
Post merge fixes: close any open statement before the change user command and fix test case output.
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/51
-
tsmith@ramayana.hindu.god authored
in middle of block)
-
davi@moksha.com.br authored
into moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime
-
anozdrin/alik@station. authored
-
anozdrin/alik@station. authored
The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.1-maint
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.0-maint
-
kaa@polly.(none) authored
-
malff@lambda.hsd1.co.comcast.net. authored
-
- 16 Oct, 2007 14 commits
-
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge
-
malff@lambda.hsd1.co.comcast.net. authored
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
-
thek@adventure.(none) authored
test programs.
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-28318-rework
-
malff@lambda.hsd1.co.comcast.net. authored
-
kostja@bodhi.(none) authored
(this is a backward-compatible change).
-
davi@moksha.com.br authored
The problem is that currently there is no way to test the behavior of the mysql_change_user() function using the mysqltest suite because there is no internal command for it. The solution is to introduce a change_user command that can be used to test aspects of the MySQL client function mysql_change_user().
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.1-maint
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.0-maint
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-4.1-maint
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
-
thek@adventure.(none) authored
The embedded version of the server doesn't use column level grants, and the compile directive NO_EMBEDDED_ACCESS_CHECKS should be checked instead of the redundant HAVE_QUERY_CACHE (which is always the case) to determine if column level grants should be compiled or not.
-
malff@lambda.hsd1.co.comcast.net. authored
The root cause of the issue was that the CREATE FUNCTION grammar, for User Defined Functions, was using the sp_name rule. The sp_name rule is intended for fully qualified stored procedure names, like either ident.ident, or just ident but with a default database implicitly selected. A UDF does not have a fully qualified name, only a name (ident), and should not use the sp_name grammar fragment during parsing. The fix is to re-organize the CREATE FUNCTION grammar, to better separate: - creating UDF (no definer, can have AGGREGATE, simple ident) - creating Stored Functions (definer, no AGGREGATE, fully qualified name) With the test case provided, another issue was exposed which is also fixed: the DROP FUNCTION statement was using sp_name and also failing when no database is implicitly selected, when droping UDF functions. The fix is also to change the grammar so that DROP FUNCTION works with both the ident.ident syntax (to drop a stored function), or just the ident syntax (to drop either a UDF or a Stored Function, in the current database)
-