- 03 Feb, 2010 15 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.41 [merge] > revision-id: epotemkin@mysql.com-20091203132153-k8xwk3nh02n8npg4 > parent: epotemkin@mysql.com-20091202134712-4muwnr152xqkcwm7 > parent: epotemkin@mysql.com-20091203131520-93uiop1a81o9z8mb > committer: Evgeny Potemkin <epotemkin@mysql.com> > branch nick: mysql-5.0-bugteam > timestamp: Thu 2009-12-03 16:21:53 +0300 > message: > Auto-merged. > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.40 [merge] > revision-id: epotemkin@mysql.com-20091202134712-4muwnr152xqkcwm7 > parent: gshchepa@mysql.com-20091201102444-yw166t3audrojo9s > parent: epotemkin@mysql.com-20091201182845-aw0uawt6c6gwi98c > committer: Evgeny Potemkin <epotemkin@mysql.com> > branch nick: mysql-5.0-bugteam > timestamp: Wed 2009-12-02 16:47:12 +0300 > message: > Auto-merged fix for the bug#48508. > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.39 > revision-id: gshchepa@mysql.com-20091201102444-yw166t3audrojo9s > parent: joro@sun.com-20091127160731-6h2fahbh4409i841 > committer: Gleb Shchepa <gshchepa@mysql.com> > branch nick: mysql-5.0-bugteam > timestamp: Tue 2009-12-01 14:24:44 +0400 > message: > Bug #38883 (reopened): thd_security_context is not thread safe, crashes? > > The bug 38816 changed the lock that protects THD::query from > LOCK_thread_count to LOCK_thd_data, but didn't update the associated > InnoDB functions. > > 1. The innobase_mysql_prepare_print_arbitrary_thd and the > innobase_mysql_end_print_arbitrary_thd InnoDB functions have been > removed, since now we have a per-thread mutex: now we don't need to wrap > several inter-thread access tries to THD::query with a single global > LOCK_thread_count lock, so we can simplify the code. > > 2. The innobase_mysql_print_thd function has been modified to lock > LOCK_thd_data in direct way.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.38 > revision-id: joro@sun.com-20091127160731-6h2fahbh4409i841 > parent: joro@sun.com-20091127143622-bqfsmhhr2pqodsm2 > committer: Georgi Kodinov <joro@sun.com> > branch nick: fix-5.0-bugteam > timestamp: Fri 2009-11-27 18:07:31 +0200 > message: > Addendum to bug #48872: disable output in the test case because errors are > dependent on the case mode
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.35 > revision-id: joro@sun.com-20091127095944-autr58itccge4z9l > parent: satya.bn@sun.com-20091125095925-871384fcnwwa2yqt > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48872-5.0-bugteam > timestamp: Fri 2009-11-27 11:59:44 +0200 > message: > Bug #48872 : Privileges for stored functions ignored if function name > is mixed case > > Transcode the procedure name to lowercase when searching for it in the > hash. This is the missing part of the fix for bug #41049.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.29 > revision-id: joro@sun.com-20091118152410-j4tv22vf9xkb6sdz > parent: kent.boortz@sun.com-20091117164924-rscth12t9a2qog1b > committer: Georgi Kodinov <joro@sun.com> > branch nick: test-5.0-bugteam > timestamp: Wed 2009-11-18 17:24:10 +0200 > message: > Bug#48864: MySQL fails to compile on 64 bit Fedora 12 > > Fixed 2 errors in comp_err executable : > 1. Wrong (off by 1) length passed to my_checksum() > 2. strmov() was used on overlapping strings. This is > not legal according to the docs in stpcpy(). Used > the overlap safe memmove() instead.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.26 > revision-id: joro@sun.com-20091109140946-07wao5od7l1vn4x1 > parent: joro@sun.com-20091110082141-ldr8p6s1joczve2j > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48458-5.0-bugteam > timestamp: Mon 2009-11-09 16:09:46 +0200 > message: > Bug #48458: simple query tries to allocate enormous amount of > memory > > The server was doing a bad class typecast causing setting of > wrong value for the maximum number of items in an internal > structure used in equality propagation. > Fixed by not doing the wrong typecast and asserting the type > of the Item where it should be done.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.19 > revision-id: kostja@sun.com-20091103165854-7di545xruez8w207 > parent: li-bing.song@sun.com-20091103090041-zj7nedx6ok5jgges > committer: Konstantin Osipov <kostja@sun.com> > branch nick: 5.0-41756 > timestamp: Tue 2009-11-03 19:58:54 +0300 > message: > A fix and a test case for > Bug#41756 "Strange error messages about locks from InnoDB". > > In JT_EQ_REF (join_read_key()) access method, > don't try to unlock rows in the handler, unless certain that > a) they were locked > b) they are not used. > > Unlocking of rows is done by the logic of the nested join loop, > and is unaware of the possible caching that the access method may > have. This could lead to double unlocking, when a row > was unlocked first after reading into the cache, and then > when taken from cache, as well as to unlocking of rows which > were actually used (but taken from cache). > > Delegate part of the unlocking logic to the access method, > and in JT_EQ_REF count how many times a record was actually > used in the join. Unlock it only if it's usage count is 0. > > Implemented review comments.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.18 > revision-id: li-bing.song@sun.com-20091103090041-zj7nedx6ok5jgges > parent: davi.arnaut@sun.com-20091102201021-1brn7cjb1kvqg9gr > committer: <Li-Bing.Song@sun.com> > branch nick: mysql-5.0-bugteam > timestamp: Tue 2009-11-03 17:00:41 +0800 > message: > BUG#48216 Replication fails on all slaves after upgrade to 5.0.86 on master > > When a sessione is closed, all temporary tables of the session are automatically > dropped and are binlogged. But it will be binlogged with wrong database names when > the length of the temporary tables' database names are greater than the > length of the current database name or the current database is not set. > > Query_log_event's db_len is forgot to set when Query_log_event's db is set. > This patch wrote code to set db_len immediately after db has set.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.4.1 > revision-id: alexey.kopytov@sun.com-20091030155453-0vlfwki805h9os62 > parent: joerg@mysql.com-20091016122941-rf6z0keqvmlgjfto > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com> > branch nick: my50-bug48131 > timestamp: Fri 2009-10-30 18:54:53 +0300 > message: > Bug #48131: crash group by with rollup, distinct, filesort, > with temporary tables > > There were two problems the test case from this bug was > triggering: > > 1. JOIN::rollup_init() was supposed to wrap all constant Items > into another object for queries with the WITH ROLLUP modifier > to ensure they are never considered as constants and therefore > are written into temporary tables if the optimizer chooses to > employ them for DISTINCT/GROUP BY handling. > > However, JOIN::rollup_init() was called before > make_join_statistics(), so Items corresponding to fields in > const tables could not be handled as intended, which was > causing all kinds of problems later in the query execution. In > particular, create_tmp_table() assumed all constant items > except "hidden" ones to be removed earlier by remove_const() > which led to improperly initialized Field objects for the > temporary table being created. This is what was causing crashes > and valgrind errors in storage engines. > > 2. Even when the above problem had been fixed, the query from > the test case produced incorrect results due to some > DISTINCT/GROUP BY optimizations being performed by the > optimizer that are inapplicable in the WITH ROLLUP case. > > Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations > when the WITH ROLLUP modifier is present, and splitting the > const-wrapping part of JOIN::rollup_init() into a separate > method which is now invoked after make_join_statistics() when > the const tables are already known.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.13 > revision-id: joro@sun.com-20091030131543-2b23fnqckgbzvete > parent: joro@sun.com-20091030094044-quadg0bwjy7cwqzw > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48291-5.0-bugteam > timestamp: Fri 2009-10-30 15:15:43 +0200 > message: > Bug #48291 : crash with row() operator,select into @var, and > subquery returning multiple rows > > Error handling was missing when handling subqueires in WHERE > and when assigning a SELECT result to a @variable. > This caused crash(es). > > Fixed by adding error handling code to both the WHERE > condition evaluation and to assignment to an @variable.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.12 > revision-id: joro@sun.com-20091030094044-quadg0bwjy7cwqzw > parent: joro@sun.com-20091029152429-ks55fhrp4lhknyij > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48293-5.0-bugteam > timestamp: Fri 2009-10-30 11:40:44 +0200 > message: > Bug #48293: crash with procedure analyse, view with > 10 columns, > having clause... > > The fix for bug 46184 was not very complete. It was not covering > views using temporary tables and multiple tables in a FROM clause. > Fixed by reverting the fix for 46184 and making a more general > check that is checking at the right execution stage and for all > of the non-supported cases. > Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden. > Updated the analyse.test and subselect.test accordingly.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.6 > revision-id: joro@sun.com-20091021084345-iki6z0uceieoupey > parent: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e > committer: Georgi Kodinov <joro@sun.com> > branch nick: B47780-5.0-bugteam > timestamp: Wed 2009-10-21 11:43:45 +0300 > message: > Bug #47780: crash when comparing GIS items from subquery > > If the first argument to GeomFromWKB function is a geometry > field then the function just returns its value. > However in doing so it's not preserving first argument's > null_value flag and this causes unexpected null value to > be returned to the calling function. > > Fixed by updating the null_value of the GeomFromWKB function > in such cases (and all other cases that return a NULL e.g. > because of not enough memory for the return buffer).
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.5 > revision-id: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e > parent: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b48258-5.0-bugteam > timestamp: Fri 2009-10-23 16:26:48 +0500 > message: > Fix for bug#48258: Assertion failed when using a spatial index > > Problem: involving a spatial index for "non-spatial" queries > (that don't containt MBRXXX() functions) may lead to failed assert. > > Fix: don't use spatial indexes in such cases.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.4 > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b47019-5.0-bugteam > timestamp: Wed 2009-10-21 14:04:08 +0500 > message: > Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, > 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.
-
- 02 Feb, 2010 1 commit
-
-
sunanda.menon@sun.com authored
-
- 14 Oct, 2009 1 commit
-
-
Hery Ramilison authored
Put variable declaration at the beginning of a block
-
- 06 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 05 Oct, 2009 1 commit
-
-
Frazer Clement authored
-
- 04 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 02 Oct, 2009 1 commit
-
-
Jonathan Perkin authored
-
- 30 Sep, 2009 6 commits
-
-
Davi Arnaut authored
Removes the need of a hack (the jump to label).
-
Davi Arnaut authored
-
Davi Arnaut authored
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.
-
Jonathan Perkin authored
Make configure.js bail with an error if trying to build bdb from a bzr tree.
-
Kristofer Pettersson authored
'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
-
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.
-
- 29 Sep, 2009 2 commits
-
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
replication MySQL server uses wrong lock type (always TL_READ instead of TL_READ_NO_INSERT when appropriate) for tables used in subqueries of UPDATE statement. This leads in some cases to a broken replication as statements are written in the wrong order to the binlog.
-
- 28 Sep, 2009 3 commits
-
-
Jonathan Perkin authored
-
Jonathan Perkin authored
Add --help option.
-
Joerg Bruehe authored
Solaris binary packages should be compiled with '-g0', not '-g'
-
- 21 Sep, 2009 1 commit
-
-
hery.ramilison@sun.com authored
-
- 18 Sep, 2009 1 commit
-
-
Georgi Kodinov authored
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.
-
- 28 Sep, 2009 1 commit
-
-
Magnus Blåudd authored
-
- 24 Sep, 2009 1 commit
-
-
Magnus Blåudd authored
- 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
-
- 17 Sep, 2009 1 commit
-
-
Joerg Bruehe authored
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.
-
- 11 Sep, 2009 1 commit
-
-
Georgi Kodinov authored
Initialize correctly client flags for the embedded client Test cases in jp updated to work correctly with embedded server.
-
- 24 Sep, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 18 Sep, 2009 1 commit
-
-
Georgi Kodinov authored
-