| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |\ |
|
| | |\ |
|
| | | |\ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This bug could result in returning 0 for the expressions of the form
<aggregate_function>(distinct field) when the system variable
max_heap_table_size was set to a small enough number.
It happened because the method Unique::walk() did not support
the case when more than one pass was needed to merge the trees
of distinct values saved in an external file.
Backported a fix in grant_lowercase.test from mariadb 5.5.
|
| | | |/
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
information_schema table due to incorrect mutexes handling
Early evaluation of subqueries in the WHERE conditions on I_S.*_STATUS tables,
otherwise the subquery on this same table will try to acquire LOCK_status twice.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The original patch with the implementation of virtual columns
did not support INSERT DELAYED into tables with virtual columns.
This patch fixes the problem.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The problem was that maybe_null of Item_row and its componetes was unsynced after update_used_tables() (and so pushed_cond_guards was not initialized but then requested).
Fix updates Item_row::maybe_null on update_used_tables().
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
functions in WHERE clause of UPDATE or DELETE statements
Analysis
The reason for the less efficient plan was result of a prior design decision -
to limit the eveluation of constant expressions during optimization to only
non-expensive ones. With this approach all stored procedures were considered
expensive, and were not evaluated during optimization. As a result, SPs didn't
participate in range optimization, which resulted in a plan with table scan
rather than index range scan.
Solution
Instead of considering all SPs expensive, consider expensive only those SPs
that are non-deterministic. If an SP is deterministic, the optimizer will
checj if it is constant, and may eventually evaluate it during optimization.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
This fixed failing test in group_by.test
|
| | | |
| | | |
| | | |
| | | | |
Subquery turned into constant too late to be excluded from grouping list so test for constant added to the create_temp_table().
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The bug could lead to a wrong estimate of the number of expected rows
in the output of the EXPLAIN commands for queries with GROUP BY.
This could be observed in the test case for LP bug 934348.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
(even if the server and libraries itself use stpcpy instead of it)
It is a workaround that allows myodbc built by certain distributions' (CentOS,Fedora) to peacefully coexist with mariadb client libraries.
The problem is that MyODBC in these distros needs strmov() to be exported by mysql client shared library, or else myodbc fails to load.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
XtraDB engine
|
| | | |
| | | |
| | | |
| | | | |
test suite added.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
not in MariaDB-5.5.23-client (CentOS 5)
Same as for deb: don't add mytop to the client rpm.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
_mi_pack_key with an index on a POINT column
sel_arg_range_seq_next(): set keypart map also for GEOM_FLAG keys
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
information_schema table due to incorrect mutexes handling
Early evaluation of subqueries in the WHERE conditions on I_S.*_STATUS tables,
otherwise the subquery on this same table will try to acquire LOCK_status twice.
sql/item.h:
remove unused method
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
jre-1.7.0_09-fcs.i586 on Fedora 18
fix the rpm packaging to work on Fedora18. Two problems:
* conflicts on common directories with other packages.
* more auto-generated requirements for mariadb-test.rpm
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
initialize cache_mngr and write the Xid into binlog even
if binlog is disabled with SQL_LOG_BIN=0 or no --log-slave-updates
in the slave thread
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Add a test case.
The fix comes with MySQL bug#15948123: SERVER WORKS INCORRECT WITH LONG TABLE ALIASES
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
mysql_performance_tables.sql was split off mysql_system_tables.sql
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixed failing test in group_by.test
mysql-test/r/join_outer.result:
Updated test case
mysql-test/r/join_outer_jcl6.result:
Updated test case
sql/item.cc:
Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
sql/item.h:
Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
sql/item_cmpfunc.h:
Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
|
| | | | |
|
|\ \ \ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Using too long table aliases in stored routines might
have caused server crashes.
Code in sp_head::merge_table_list() which is responsible
for collecting information about tables used in stored
routine was not aware of the fact that table alias might
have arbitrary length. I.e. it assumed that table alias
can't be longer than NAME_LEN bytes and allocated buffer
for a key identifying table accordingly.
This patch fixes the issue by ensuring that we use
dynamically allocated buffer for table key when table
alias is too long. By default stack based buffer is used
in which NAME_LEN bytes are reserved for table alias.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Description: A very large database name causes buffer
overflow in functions acl_get() and
check_grant_db() in sql_acl.cc. It happens
due to an unguarded string copy operation.
This puts required sanity checks before
copying db string to destination buffer.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
After-push cleanup: removal of unneeded assertions.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Code in MDL subsystem assumes that identifiers of objects can't
be longer than NAME_LEN characters. This assumption was broken
when one tried to construct MDL_key based on table alias, which
can have arbitrary length. Since MDL_key's (and MDL locks) are
not really used for table aliases this patch changes code to
not initialize MDL_key object for table list element representing
aliases.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The patch "mysql-chain-certs.patch" needs to be adapted
to code changes in "vio/viosslfactories.c" which were
done in MySQL 5.5.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Top level "SPECIFIC-ULN/" was inappropriate,
put the files to create RPMs for ULN into
"packaging/rpm-uln/".
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Problem description:
mysql server crashes when we run repair table on currupted table.
Analysis:
The problem with this bug seem to be key_reflength out of bounds
(186 according to debugger). We read this value from meta-data
segment of .MYI file while doing mi_open().
If you look into _mi_kpointer() you can see that the upper limit
for key_reflength is 7.
Solution:
In mi_open() there is a line like:
if (share->base.keystart > 65535 || share->base.rec_reflength > 8)
we should verify key_reflength here as well.
|
| |\ \ \ \ \ \ |
|
| |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
DISABLE AND ENABLED DURING DDL OPERATION
PROBLEM: Same thread trying to acquire the same mutex
second time leads to hang/server crash.
While [un]installing audit_log plugin
a thread acquires the LOCK_plugin mutex
and after successful initialization tries
to write in mysql.plugin table. It holds
this mutex for a long time. If some how
plugin table is corrupted then a write to
plugin table will throw an error, thread try
to log this error in the audit_log plugin,
doing so it tries to acquire the mutex
again and results is server hang/crash.
SOLUTION: Releasing the LOCK_plugin mutex before
writing in mysql.plugin table. We dont
need to hold this mutex as thread already
acquired a TL_WRITE lock on mysql.plugin
table.
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
TO MYISAM_SORT_BUFFER_SIZE
Null Merge from 5.1 to 5.5
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
TO 'MYISAM_SORT_BUFFER_SIZE'
Merging from 5.1 to 5.5
|