| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
line 138 when forcing a spatial index
Problem: "Spatial indexes can be involved in the search
for queries that use a function such as MBRContains()
or MBRWithin() in the WHERE clause".
Using spatial indexes for JOINs with =, <=> etc.
predicates is incorrect.
Fix: disable spatial indexes for such queries.
mysql-test/r/select.result:
Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c,
line 138 when forcing a spatial index
- test result.
mysql-test/t/select.test:
Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c,
line 138 when forcing a spatial index
- test case.
sql/sql_select.cc:
Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c,
line 138 when forcing a spatial index
- disable spatial indexes for queries which use
non-spatial conditions (e.g. NATURAL JOINs).
|
| |\ |
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
grants are reapplied.
After renaming a user and trying to re-apply grants results in additional
grants.
This is because we use username as part of the key for GRANT_TABLE structure.
When the user is renamed, we only change the username stored and the hash key
still contains the old user name and this results in the extra privileges
Fixed by rebuilding the hash key and updating the column_priv_hash structure
when the user is renamed
mysql-test/r/grant3.result:
Bug #41597 - After rename of user, there are additional grants when
grants are reapplied.
Testcase for BUG#41597
mysql-test/t/grant3.test:
Bug #41597 - After rename of user, there are additional grants when
grants are reapplied.
Testcase for BUG#41597
sql/sql_acl.cc:
Bug #41597 - After rename of user, there are additional grants when
grants are reapplied.
Fixed handle_grant_struct() to update the hash key when the user is renamed.
Added to set_user_details() method to GRANT_NAME class
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
shutdown)
If a thread is killed in the server, we throw "shutdown" only if one is actually in
progress; otherwise, we throw "query interrupted".
Control-C in the mysql command-line client is "incremental" now.
First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next)
Next Control-C sends KILL CONNECTION
Next Control-C aborts client.
As the first two steps only pertain to an existing query,
Control-C will abort the client right away if no query is running.
client will give more detailed/consistent feedback on Control-C now.
client/mysql.cc:
Extends Control-C handling; enhances up feedback to user.
On 5.0+ servers, we try to be nice and send KILL QUERY first
if Control-C is pressed in the command-line client, but if
that doesn't work, we now give the user the opportunity to
send KILL CONNECTION with another Control-C (and to kill the
client with another Control-C if that somehow doesn't work
either).
mysql-test/t/flush_read_lock_kill.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/kill.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/rpl000001.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/rpl_error_ignored_table.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
sql/records.cc:
make error messages on KILL uniform for rr_*()
by folding that handling into rr_handle_error()
sql/sql_class.h:
Only throw "shutdown" when we have one flagged as being in progress;
otherwise, throw "query interrupted" as it's likely to be "KILL CONNECTION"
or related.
|
| |\ \ |
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Use "#ifdef", not plain "#if".
|
| | |\ \ \
| | |/ / |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The bug is a compilation issue:
Function "find_key_block()" had thread operations
which were not guarded by "#if THREAD", add that now.
mysys/mf_keycache.c:
Without thread-support, we are in a single-threaded world,
so there is no parallelism, and the keycache cannot be
within a resize operation while this request is being processed.
|
| |/ / / |
|
| |\ \ \
| |_|/
|/| | |
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
> ------------------------------------------------------------
> revno: 2802.1.1
> tags: mysql-5.0.86
> revision-id: hery.ramilison@sun.com-20090909185217-mooeczu391ztp2fz
> parent: joro@sun.com-20090902123318-8qe40pr91xmui5ue
> committer: hery <hery.ramilison@sun.com>
> branch nick: mysql-5.0.86-release
> timestamp: Wed 2009-09-09 20:52:17 +0200
> message:
> change c++ comment to c comment
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
> ------------------------------------------------------------
> revno: 2796
> revision-id: sergey.glukhov@sun.com-20090827102219-sgjz0v5t1rfccs14
> parent: joro@sun.com-20090824122803-1d5jlaysjc7a7j6q
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Thu 2009-08-27 15:22:19 +0500
> message:
> Bug#46184 Crash, SELECT ... FROM derived table procedure analyze
> The crash happens because select_union object is used as result set
> for queries which have derived tables.
> select_union use temporary table as data storage and if
> fields count exceeds 10(count of values for procedure ANALYSE())
> then we get a crash on fill_record() function.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
> ------------------------------------------------------------
> revno: 2791.2.3
> revision-id: joro@sun.com-20090827114042-h55n7qp9990bl6ge
> parent: anurag.shekhar@sun.com-20090831073231-e55y1hsck6n08ux8
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B46749-5.0-bugteam
> timestamp: Thu 2009-08-27 14:40:42 +0300
> message:
> Bug #46749: Segfault in add_key_fields() with outer subquery level
> field references
>
> This error requires a combination of factors :
> 1. An "impossible where" in the outermost SELECT
> 2. An aggregate in the outermost SELECT
> 3. A correlated subquery with a WHERE clause that includes an outer
> field reference as a top level WHERE sargable predicate
>
> When JOIN::optimize detects an "impossible WHERE" it will bail out
> without doing the rest of the work and initializations. It will not
> call make_join_statistics() as well. And make_join_statistics fills
> in various structures for each table referenced.
> When processing the result of the "impossible WHERE" the query must
> send a single row of data if there are aggregate functions in it.
> In this case the server marks all the aggregates as having received
> no rows and calls the relevant Item::val_xxx() method on the SELECT
> list. However if this SELECT list happens to contain a correlated
> subquery this subquery is evaluated in a normal evaluation mode.
> And if this correlated subquery has a reference to a field from the
> outermost "impossible where" SELECT the add_key_fields will mistakenly
> consider the outer field reference as a "local" field reference when
> looking for sargable predicates.
> But since the SELECT where the outer field reference refers to is not
> completely initialized due to the "impossible WHERE" in this level
> we'll get a NULL pointer reference.
> Fixed by making a better condition for discovering if a field is "local"
> to the SELECT level being processed.
> It's not enough to look for OUTER_REF_TABLE_BIT in this case since
> for outer references to constant tables the Item_field::used_tables()
> will return 0 regardless of whether the field reference is from the
> local SELECT or not.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |_|/
|/| | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
can lead to bad memory access
Problem: Field_bit is the only field which returns INT_RESULT
and doesn't have unsigned flag. As it's not a descendant of the
Field_num, so using ((Field_num *) field_bit)->unsigned_flag may lead
to unpredictable results.
Fix: check the field type before casting.
mysql-test/r/type_bit.result:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- test result.
mysql-test/t/type_bit.test:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- test case.
sql/opt_range.cc:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- don't cast to (Field_num *) Field_bit, as it's not a Field_num
descendant and is always unsigned by nature.
|
| |\ \ \
| |/ / |
|
| | | | |
|
| | |\ \ |
|
| | | |\ \
| | | | |
| | | | |
| | | | |
| | | | | |
Solaris binary packages should be compiled with '-g0', not '-g'
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Solaris binary packages should be compiled with '-g0', not '-g'
The main fix for this is done in the build tools,
but in the sources it affects "configure.in"
which sets "DEBUG_CXXFLAGS" to be used in all debug builds.
|
| | |\ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Make configure.js bail with an error if trying to build bdb from a bzr
tree.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Removes the need of a hack (the jump to label).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
sql/sql_parse.cc:
DBUG macros are wrapped inside a loop. Allow to break
the command switch from within a DBUG macro.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
On Mac OS X or Windows, sending a SIGHUP to the server or a
asynchronous flush (triggered by flush_time), would cause the
server to crash.
The problem was that a hook used to detach client API handles
wasn't prepared to handle cases where the thread does not have
a associated session.
The solution is to verify whether the thread has a associated
session before trying to detach a handle.
mysql-test/r/federated_debug.result:
Add test case result for Bug#47525
mysql-test/t/federated_debug-master.opt:
Debug point.
mysql-test/t/federated_debug.test:
Add test case for Bug#47525
sql/slave.cc:
Check whether a the thread has a associated session.
sql/sql_parse.cc:
Add debug code to simulate a reload without thread session.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The pthread_cond_wait implementations for windows might
dead lock in some rare circumstances.
1) One thread (I) enter a timed wait and at a point in
time ends up after mutex unlock and before
WaitForMultipleObjects(...)
2) Another thread (II) enters pthread_cond_broadcast.
Grabs the mutex and discovers one waiter. It set
the broadcast event and closes the broadcast gate
then unlocks the mutex.
3) A third thread (III) issues a pthread_cond_signal.
It grabs the mutex, discovers one waiter, sets the
signal event then unlock the mutex.
4) The first threads (I) enters WaitForMultipleObjects
and finds out that the signal object is in a
signalled state and exits the wait.
5) Thread (I) grabs the mutex and checks result status.
The number of waiters is decreased and becomes equal
to 0. The event returned was a signal event so the
broadcast gate isn't opened. The mutex is released.
6) Thread (II) issues a new broadcast. The mutex is
acquired but the number of waiters are 0 hence
the broadcast gate remains closed.
7) Thread (I) enters the wait again but is blocked by
the broadcast gate.
This fix resolves the above issue by always resetting
broadcast gate when there are no more waiters in th queue.
mysys/my_wincond.c:
* Always reset the broadcast gate if there are no more waiters left.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
'flush tables' crashes
The server crashes when 'show procedure status' and 'flush tables' are
run concurrently.
This is caused by the way mysql.proc table is added twice to the list
of table to lock although the requirements on the current locking API
assumes differently.
No test case is submitted because of the nature of the crash which is
currently difficult to reproduce in a deterministic way.
This is a backport from 5.1
myisam/mi_dbug.c:
* check_table_is_closed is only used in EXTRA_DEBUG mode but since it is
iterating over myisam shared data it still needs to be protected by an
appropriate mutex.
sql/sql_yacc.yy:
* Since the I_S mechanism is already handling the open and close of
mysql.proc there is no need for the method sp_add_to_query_tables.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
in a transaction
The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the
database is not selected by --database option of mysqlbinlog command.
This can result in problem if there are some statements in the
transaction are not filtered out.
To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT'
in regardless of the database filtering rules.
client/mysqlbinlog.cc:
Skip the database check for BEGIN/COMMIT/ROLLBACK log events.
mysql-test/r/mysqlbinlog.result:
Test result for bug#46998
mysql-test/t/mysqlbinlog.test:
Added test to verify if the 'BEGIN', 'COMMIT' and 'ROLLBACK' are output
in regardless of database filtering
|
| |\ \ \ \ \
| |/ / / / |
|
| | |\ \ \ \ |
|
| | | |/ / /
| | | | |
| | | | |
| | | | |
| | | | | |
Add --help option.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
query
The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT
and substituted it for a check on the presence of
Item_ident::depended_from.
Removing it altogether was wrong : OUTER_REF_TABLE_BIT should
still be checked in addition to depended_from (because it's not
set in all cases and doesn't contradict to the check of depended_from).
Fixed by returning the old condition back as a compliment to the
new one.
|
| | |\ \ \ \ |
|
| | | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- Create the "dummy" thread joinable and wait for it to
exit before continuing in 'my_thread_global_init'
- This way we know that the pthread library is initialized
by one thread only
|
| | | |\ \ \ |
|
| | | | |/ / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Initialize correctly client flags for the embedded client
Test cases in jp updated to work correctly with embedded server.
|
| | | | | | |
|
| | |\ \ \ \
| | |/ / / |
|
| | | |/ / |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When parsing the service installation parameter in
default_service_handling() make sure the value of the
optional parameter doesn't overwrite it's name.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
with gcc 4.3.2
This is the fifth patch cleaning up more GCC warnings about
variables used before initialized using the new macro
UNINIT_VAR().
|
| | |\ \ \ |
|
