view that has Group By
When SELECT'ing from a view that mentions another,
materialized, view, access was being denied. The issue was
resolved by lifting a special case which avoided such access
checking in check_single_table_access. In the past, this was
necessary since if such a check were performed, the error
message would be downgraded to a warning in the case of SHOW
CREATE VIEW. The downgrading of errors was meant to handle
only that scenario, but could not distinguish the two as it
read only the error messages.
The special case was needed in the fix of bug no 36086.
Before that, views were confused with derived tables.
After bug no 35996 was fixed, the manipulation of errors
during SHOW CREATE VIEW execution is not dependent on the
actual error messages in the queue, it rather looks at the
actual cause of the error and takes appropriate
action. Hence the aforementioned special case is now
superfluous and the bug is fixed.
Implemented the server infrastructure for the fix:
1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of
thd_query()
2. Did some encapsulation in THD : aggregated thd_query and
thd_query_length into a LEX_STRING and made accessor and mutator
methods for easy code updating.
3. Updated the server code to use the new methods where applicable.
------------------------------------------------------------
revno: 2476.657.208
committer: anozdrin/alik@station.
timestamp: Tue 2007-12-04 17:22:53 +0300
message:
Remove rpl_probe, enable_rpl_parse and disable_rpl_parse commands
from mysqltest, the corresponding funtctions have been removed from
MySQL C API
------------------------------------------------------------
revno: 2476.981.1
committer: msvensson@pilot.mysql.com
timestamp: Mon 2007-11-26 19:03:23 +0100
message:
Bug#31952 Remove undocumented mysql_rpl_* functions.
- Functions removed + variables in st_mysql and st_mysql_options
renamed to "unused".
- Code updated to work without those functions and variables
revno: 2630.22.41
committer: Alexander Nozdrin <alik@mysql.com>
branch nick: 6.0-rt-bug39255
timestamp: Thu 2008-10-16 16:39:30 +0400
message:
A patch for Bug#39255: Stored procedures: crash if function
references nonexistent table.
The problem is not reproduced in 6.0. Adding a test case.
redefining trigger
The 'table->auto_increment_field_not_null' flag is only valid within
processing of a single row, and should be set to FALSE before
navigating to the next row, or exiting the operation.
This bug was caused by an SQL error occuring while executing a trigger
after the flag had been set, so the normal resetting was bypassed.
The table object was then returned to the table share's cache in
a dirty condition. When the table object was reused, an assert
caught that the flag was set.
This patch explicitly clears the flag on error/abort.
Backported from mysql-6.0-codebase revid: 2617.52.1
The fix for Bug #38124 introuced a bug. If the value given
for a set_var exceeded the length of the temporary buffer,
we would read behind the end of the buffer. Using
c_ptr_safe(), instead of c_ptr(), ensures that we won't
read beyond the buffer limit
mysql-6.0-codebase revid: 2617.44.1
get_table_share, drop_open_table
In the partition handler code, LOCK_open and share->LOCK_ha_data
are acquired in the wrong order in certain cases. When doing a
multi-row INSERT (i.e a INSERT..SELECT) in a table with auto-
increment column(s). the increments must be in a monotonically
continuous increasing sequence (i.e it can't have "holes"). To
achieve this, a lock is held for the duration of the operation.
share->LOCK_ha_data was used for this purpose.
Whenever there was a need to open a view _during_ the operation
(views are not currently pre-opened the way tables are), and
LOCK_open was grabbed, a deadlock could occur. share->LOCK_ha_data
is other places used _while_ holding LOCK_open.
A new mutex was introduced in the HA_DATA_PARTITION structure,
for exclusive use of the autoincrement data fields, so we don't
need to overload the use of LOCK_ha_data here.
A module test case has not been supplied, since the problem occurs
as a result of a race condition, and testing for this condition
is thus not deterministic. Testing for it could be done by
setting up a test case as described in the bug report.
When assigning the new string value to the variable, the
Item::str_value member was used. This is not according to
the protocol. str_value is an internal member used for
temporary assignments, and is not consistently set for all
string operations. It is set for constant strings, so it would
work in these cases, but not for string functions (concat,
substr, etc.)
The correct approach is to use Item::val_str(..) to evaluate
and retrieve the string.
Backport from 6.0-codebase
6.0-codebase revno: 2617.31.17
Fix a regression that crept in when downporting Windows improvements.
Instead of a shutdown thread, another thread that handledsocket connection was created.
Temporary tables may set join->group to 0 even though there is
grouping. Also need to test if sum_func_count>0 when JOIN::exec()
decides whether to present results in a grouped manner.
----------------------------------------------------------
revno: 2630.28.1
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Thu 2008-10-23 15:23:44 +0400
message:
Bug#32738 "mysqld: Two slow log option/variable descriptions are
inaccurate"
Update option description per suggestion from the documentation team.
