Re: [Maria-developers] Strange code in 5.2 & Assigned bugs
Hi!
On 08.08.2010 09:09, Michael Widenius wrote:
Hi!
Sanja, in Aria engine in 5.2 we have the code:
else
{
soft_sync_max= lsn;
soft_need_sync= 1;
}
This is likely wrong as soft_sync_max is supposed to be a file number
and lsn is too big to fix into soft_sync_max (which is only a uint32).
Could you please take a look at this.
Fixed & pushed.
Note that I also assigned the following bug in 5.2 for you to take a
look at:
#611379 Equivalent queries with Impossible where return different results
It is also present it 5.1. I made patch for it (needs review) and I
doubts which version it should go.
Please also try to get this one fixed (as it's marked 5.1):
#473914 mysql_client_test fail on windows x64
I'll talk to Bo, I think he already fixed it.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 2816: Fixed second part of the LP BUG#615760 - incorrect parameters of the temporary heap table index (unique & nulls are equal). in file:///home/bell/maria/bzr/wo
Hi!
On 07.09.2010 17:49, Sergei Golubchik wrote:
Hi, Sanja!
On Sep 07, sa...@askmonty.org wrote:
At file:///home/bell/maria/bzr/work-maria-5.3-lb615760/
revno: 2816
revision-id: sa...@askmonty.org-20100907061732-yyuwtfg0ucyqiu8j
parent: sa...@askmonty.org-20100906123424-2sco3ghittvidm6l
committer: sa...@askmonty.org
branch nick: work-maria-5.3-lb615760
timestamp: Tue 2010-09-07 09:17:32 +0300
message:
Fixed second part of the LP BUG#615760 - incorrect parameters of the
temporary heap table index (unique& nulls are equal).
=== modified file 'sql/sql_expression_cache.cc'
--- a/sql/sql_expression_cache.cc 2010-09-06 12:34:24 +
+++ b/sql/sql_expression_cache.cc 2010-09-07 06:17:32 +
I cannot review that change, I don't know sql_expression_cache code :(
Anyway, you asked me to look at the "incorrect heap table index flags"
changes only.
=== modified file 'sql/table.cc'
--- a/sql/table.cc 2010-07-10 10:37:30 +
+++ b/sql/table.cc 2010-09-07 06:17:32 +
@@ -5191,7 +5191,7 @@
keyinfo->usable_key_parts= keyinfo->key_parts = key_parts;
keyinfo->key_length=0;
keyinfo->algorithm= HA_KEY_ALG_UNDEF;
- keyinfo->flags= HA_GENERATED_KEY;
+ keyinfo->flags= HA_GENERATED_KEY | HA_NOSAME;
sprintf(buf, "key%i", key);
if (!(keyinfo->name= strdup_root(&mem_root, buf)))
return TRUE;
@@ -5230,6 +5230,7 @@
{
key_part_info->store_length+= HA_KEY_NULL_LENGTH;
keyinfo->key_length+= HA_KEY_NULL_LENGTH;
+ keyinfo->flags|= HA_NULL_ARE_EQUAL; // def. that NULL == NULL
}
if ((*reg_field)->type() == MYSQL_TYPE_BLOB ||
(*reg_field)->real_type() == MYSQL_TYPE_VARCHAR)
Difficult to say.
Sure, temporary tables should have keyinfo->flags=HA_NOSAME and
keyinfo->flags|= HA_NULL_ARE_EQUAL. You can see that in
create_tmp_table(). HA_GENERATED_KEY has no effect, so it doesn't matter
if you specify it or not.
But I don't know what are requirements for temporary tables in your
subquery cache code.
I need unique index on almost all fields (actually primary index).
Unrelated question - why did you duplicate creation of temporary
tables? I understand that you may've needed something slightly different
from create_tmp_table(), but then you should've changed
create_tmp_table() to use your new code, TABLE::add_tmp_key() etc.
The function is not mine, and it is made by Evgen in 6.0 then redone by
Igor, and here is good point, AFAIK Igor will need not only unique
indeces for his tables.
By the way, if you had done that (reused the code, not duplicated it)
this bug would've been impossible - many tests in the test suite would
fail at once if all temporary tables would have non-unique indexes.
Everything we have in create_tmp_table is not suitable for my task and
especially for Igor task. He creates all possible useful indeces over
temporary table which, then drop unneeded and use only suitable for join
optimisation. So it could not be done in one function, and need several
calls to add index by index.
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 2939: Fixed bug #53161. in file:///home/igor/maria/maria-5.1-bug53161/
Hi! On 21.09.2010 07:22, i...@askmonty.org wrote: At file:///home/igor/maria/maria-5.1-bug53161/ revno: 2939 revision-id: i...@askmonty.org-20100921042200-o52vwhnkz6kuwrcn parent: mo...@askmonty.org-20100915130103-x6i3x2mjc5gxsu77 committer: Igor Babaev branch nick: maria-5.1-bug53161 timestamp: Mon 2010-09-20 21:22:00 -0700 message: Fixed bug #53161. The implementation of the virtual method not_null_tables for the class Item_outer_ref must always return 0. Patch looks OK, thanks. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] subselect_cache fails
Hi! 18 окт. 2010, в 20:55, Sergey Petrunya написал(а): Hi Sanja, subselect_cache fails on sol-sparc-32 in current 5.3-merge-from-5.2: http://buildbot.askmonty.org/buildbot/builders/sol-sparc-32/builds/575/steps/test/logs/stdio Any idea about this? It looks like subquery cache just switched off (probably can't create temporary table, but I'll investigate it more) Have we observed such failure before or it has appeared in the merge? Nobody could observe something on that sun and mac32. That platforms had had no ability to build 5.3 before merge (was waiting merge from 5.1 with workaround about old gcc problem with some optimization) ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Problem with prep_where (LP BUG#675248)
Preparation statement for PS looks like this (example uses prep_where,
but we have the same problem for other parts stored in
st_select_lex::fix_prepare_information()):
...
conds->fix_fields(...&conds...) /* (1.1) JOIN::prepare()*/
...
prep_where= *conds; /* (1.2)
st_select_lex::fix_prepare_information() */
*conds= where= prep_where->copy_andor_structure()
...
Then executing of the prepared statement is like this:
where= prep_where->copy_andor_structure() /* (2.1) reinit_stmt_before_use */
...
where->fix_fields() /* (2.2) JOIN::prepare() */
...
The problem is that during (1.1) we could substitute conds with
reference on other item (for example if we change reference on
Item_field on Item_ref* or Item_ref on Item_field). The new item will be
destroyed after preparation (i.e before (2.1)). So during (2.1)
prep_where points on freed memory.
How to solve the problem.
1. Workarounds
1.1. Make changing Items inherited from Item_ident (Item_field and
Item_ref*) during resolving permanent.
Pros:
- Looks logical
- reduce work during second preparation
Cons:
- Play with statement memory usually complex enough.
- have to be sure that there is no any reference on the original Item
1.2 Add new method for Item, which return 'this' pointer but for
Item_idents creating during resolving original Item. (1.2) turns to
something like:
prep_where= (*conds)->original_ident_item();
Pros:
- Looks simple
Cons:
- Item already overloaded with methods like this
1.3 Assign prep_where before (1.1)
Pros:
- Easy to implement
Cons:
- Need changing logic and semantic of some calls and
prep_where/prep_having... class variables.
2. Global solutions for the problem of double/triple/... reference on
transformed expression (it is not applicadle for 5.1-5.3 but could de
universal solution in 5.5 of higher):
2.1 Absolutely transparent wrapper to save only one reference on any
expression which could be transformed:
Pros:
- Could base class for many other wrappers
Cons:
- It is difficult to implement such absolutely transparent wrapper.
- A lot of places where it should be put, make Item tree bigger
2.2 Turn THD::change_list to hash (for example) and chack presence
of assigning variable in the list, if it found, also register changing
for variable we are assigning value now. For example instead of
prep_where= *conds; use thd->assign_changeable(&prep_where, conds), where:
void THD::assign_changeable(void **newref, void **oldref)
{
if (in_changed_references(oldref)
change_item_tree(newref, *oldref);
else
*newref= *oldref;
}
Pros:
- no additional work for usual statements
Cons:
- List supports order of assigments easyly, but hash can't
- time for finding pointers in the hash
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Branch ~maria-captains/maria/5.1] Rev 2988: Fix LP Bug#686184 - merge_debug test fails.
Hi!
On 07.12.2010 01:15, nore...@launchpad.net wrote:
revno: 2988
fixes bug(s): https://launchpad.net/bugs/686184
committer: Vladislav Vaintroub
branch nick: 5.1
timestamp: Mon 2010-12-06 22:34:50 +0100
message:
Fix LP Bug#686184 - merge_debug test fails.
The reason for failure is that DBUG_EXECUTE_IF in mi_open()
only worked for Unix-formatted file names, due to strstr(name, "/crashed")
The fix change strstr() above to strstr(name, "crashed"), to it can work with
Windows file names as well.
modified:
storage/myisam/mi_open.c
(M)Aria engine also has code like you fixed above in ma_open.c:
DBUG_EXECUTE_IF("maria_pretend_crashed_table_on_open",
if (strstr(name, "/t1"))
{
my_errno= HA_ERR_CRASHED;
goto err;
});
Should it be also fixed?
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 2867: Fix LP BUG#685411 in file:///home/tsk/mprog/src/5.3-lpb-685411/
Hi! On 14.12.2010 14:08, tim...@askmonty.org wrote: At file:///home/tsk/mprog/src/5.3-lpb-685411/ revno: 2867 revision-id: tim...@askmonty.org-20101214120805-vafrxb6i59u9gyef parent: i...@askmonty.org-20101211205039-b1alcmyethjpddzu committer: tim...@askmonty.org branch nick: 5.3-lpb-685411 timestamp: Tue 2010-12-14 14:08:05 +0200 message: Fix LP BUG#685411 Ok, to push. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Fwd: [Commits] Rev 2998: Fixed LP bug #639935 (bug #58727). in file:///home/igor/maria/maria-5.1-bug693935/]
Hi! 24 Dec 2010, в 06:45, Igor Babaev написал(а): Sanja, Please review this fix ASAP. We need it to move on with 5.3 The patch is OK, but I would prefer to have comment before Item::quick_fix_field() that this method is only for optimizer needs, it can be used only for certain Items controlled by optimizer and maybe add that only Item_func_* need recursion for this. But you could write comments much better then I so it is up to you how write the comment. Regards. Igor. Original Message Subject: [Commits] Rev 2998: Fixed LP bug #639935 (bug #58727). in file:///home/igor/maria/maria-5.1-bug693935/ Date: Fri, 24 Dec 2010 06:42:05 +0200 (EET) From: Reply-To: maria-developers@lists.launchpad.net To: At file:///home/igor/maria/maria-5.1-bug693935/ revno: 2998 revision-id: i...@askmonty.org-20101224044150-p9yja1e87riwjh7g parent: mo...@askmonty.org-20101221172350-wqtf0t6evpc0un4b committer: Igor Babaev branch nick: maria-5.1-bug693935 timestamp: Thu 2010-12-23 20:41:50 -0800 message: Fixed LP bug #639935 (bug #58727). When the optimizer creates items out of other items it does not have to call the fix_fields method. Usually in these cases it calls quick_fix_field() that just marks the created item as fixed. If the created item is an Item_func object then calling quick_fix_field() works fine if the arguments of the created functional item are already fixed. Otherwise some unfixed nodes remain in the item tree and it triggers an assertion failure whenever the item is evaluated. Fixed the problem by making the method quick_fix_field virtual and providing an implementation for the class Item_func objects that recursively calls the method for unfixed arguments of any functional item. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] The query cache patch fixed by me and then Monty (most changes by him)
On 29.12.2010 13:00, Oleksandr Byelkin wrote: Hi! Here is changes which was done: I found a bug here, new version will be tomorrow... ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 2876: Fixed LP bug #698882. in file:///home/igor/maria/maria-5.3-bugs/
Hi! On 13.01.2011 01:11, Igor Babaev wrote: At file:///home/igor/maria/maria-5.3-bugs/ revno: 2876 revision-id: i...@askmonty.org-20110112231059-prhv2vncj6y2cizn parent: i...@askmonty.org-20110105230330-2nzlm8641wcrwzio committer: Igor Babaev branch nick: maria-5.3-bugs timestamp: Wed 2011-01-12 15:10:59 -0800 message: Fixed LP bug #698882. Made sure that the optimal fields are used by TABLE_REF objects when building index access keys to joined tables. Fixed a bug in the template function that sorts the elements of a list using the bubble sort algorithm. The bug caused poor performance of the function. Also added an optimization that skips comparison with the most heavy elements that has been already properly placed in the list. Made the comparison of the fields belonging to the same Item_equal more granular: fields belonging to the same table are also ordered according to some rules. The patch as OK. But I'd prefer to have comment that the lists are mostly short and because of this used bubble sort algorithm (or you could use more detailed explanation from your letter to me). Also in big 'if (!cmp)' used tabulation (it is visible if you check diff where layout looks not correct, but it is correct in the result file), if it is not difficult it would be better to remove them. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] review: [Commits] Rev 2875: Fix problem of making on-disk cache table. in file:///home/bell/maria/bzr/work-maria-5.3-subquerycache/
Hi!
On 14.01.2011 18:30, Michael Widenius wrote:
[skip]
@@ -225,7 +229,7 @@ my_bool Expression_cache_tmptable::put_v
DBUG_ENTER("Expression_cache_tmptable::put_value");
DBUG_ASSERT(inited);
- if (!cache_table)
+ if (!cache_table || frozen)
{
Is it not eonugh to test for 'frozen'?
(You should set frozen to 0 if cache_table is not set)
It will lead to complex enough code with double assignmend of
cache_table and frozen, also it will lead to possible errors if code
will be changed somewhere by other programmer.
[skip]
=== modified file 'sql/sql_expression_cache.h'
@@ -50,6 +50,8 @@ class Item_field;
class Expression_cache_tmptable :public Expression_cache
{
+ ulong hit, miss;
+ bool frozen;
ulong -> ulonglong (in a join you can have a LOT of row combinations)
But we use ulong for all global variables (I checked before using ulong).
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3014: New table creation/renaming block added if old encoded table present. in file:///home/bell/maria/bzr/work-maria-5.1-CREATE/
Hi! On 20.01.2011 16:04, Sergei Golubchik wrote: Hi, sanja! On Jan 13, sa...@askmonty.org wrote: revno: 3014 revision-id: sa...@askmonty.org-20110113180607-e5hc8zuugxxjtn6k parent: pser...@askmonty.org-20110112083018-90rw058f00uslvoz committer: sa...@askmonty.org branch nick: work-maria-5.1-CREATE timestamp: Thu 2011-01-13 20:06:07 +0200 message: New table creation/renaming block added if old encoded table present. First: there is no test case for the new (as compared with the previous patch) change. It just fail upgrade test which I had not noticed. Second: I think "old_path" does not belong to the check_table_file_presence() function. The function simply checks if the file exists, there is no place for the concept of "old path" here. You need to take care of the renaming for upgrade and old path outside of check_table_file_presence(). I see 2 ways to do it: 1) Add a function for cases of renaming which will do the check (but it lead for double building old-style-path) 2) change check_table_file_presence() so that it will get old-style-path path as argument and build it for both checks with renaming in some super-function and separately for creation + separate function for old-style-path building to avoid the code copy. 3) Something better? [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 2896: Fixed LP bug #707827. in file:///home/igor/maria/maria-5.3-bug707827/
Hi! On 28.01.2011 07:23, Igor Babaev wrote: At file:///home/igor/maria/maria-5.3-bug707827/ revno: 2896 revision-id: i...@askmonty.org-20110128052302-09617460yxj1kck7 parent: i...@askmonty.org-20110127044523-9kvx1t3x3166hjyr committer: Igor Babaev branch nick: maria-5.3-bug707827 timestamp: Thu 2011-01-27 21:23:02 -0800 message: Fixed LP bug #707827. This bug could manifest itself when hash join over a varchar column with NULL values in some rows was used. It happened because the function key_buf_cmp erroneously returned FALSE when one of the joined key fields was null while the second was not. Also fixed two other bugs in the functions key_hashnr and key_buf_cmp that could possibly lead to wrong results for some queries that used hash join over several columns with nulls. Also reverted the latest addition of the test case for bug #45092. It had been already backported earlier. It looks good to be pushed. Thank you for fixing it! ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 2929: Fix LP BUG#718763 in file:///home/tsk/mprog/src/5.3/
Hi!
Everything looks OK, except one small style error.
Also it would be nice to put somewhere 'TODO:' to bring in order
'uncachable' flags.
On 03.03.2011 14:07, tim...@askmonty.org wrote:
At file:///home/tsk/mprog/src/5.3/
revno: 2929
revision-id: tim...@askmonty.org-20110303120726-la5o40rldim2t93y
parent: pser...@askmonty.org-2011030107-1rmapkelx9l1kw8u
committer: tim...@askmonty.org
branch nick: 5.3
timestamp: Thu 2011-03-03 14:07:26 +0200
message:
Fix LP BUG#718763
Analysis:
The reason for the crash was that the inner subquery was executed
via a scan on a final temporary table applied after all other
operations. This final operation is implemented by changing the
contents of the JOIN object of the subquery to represent a table
scan over the temp table. At the same time query optimization of
the outer subquery required evaluation of the inner subquery, which
happened before the actual EXPLAIN. The evaluation left the JOIN
object of the inner subquery in the changed state, where it represented
a table scan over a temp table, and EXPLAIN crashed because the temp
table is not associated with any table reference (TABLE_LIST object).
The reason the JOIN was not restored was because its saving/restoration
was controlled by the join->select_lex->uncacheable flag, which was
not set in the case of materialization.
Solution:
In the methods Item_in_subselect::[single | row]_value_transformer() set:
select_lex->uncacheable|= UNCACHEABLE_EXPLAIN;
In addition, for symmetry, change:
master_unit->uncacheable|= UNCACHEABLE_EXPLAIN;
instead of UNCACHEABLE_DEPENDENT because if a subquery was not
dependent initially, the changed methods do not change this
fact. The subquery may later become correlated if it is transformed
to an EXISTS query, but it may stay uncorrelated if executed via
materialization.
[skip]
@@ -1742,7 +1752,15 @@ Item_in_subselect::row_value_transformer
optimizer->keep_top_level_cache();
thd->lex->current_select= current;
-master_unit->uncacheable|= UNCACHEABLE_DEPENDENT;
+/*
+ The uncacheable property controls a number of actions, e.g. whether to
+ save/restore (via init_save_join_tab/restore_tmp) the original JOIN for
+ plans with a temp table where the original JOIN was overriden by
+ make_simple_join. The UNCACHEABLE_EXPLAIN is ignored by EXPLAIN, thus
+ non-correlated subqueries will not appear as such to EXPLAIN.
+*/
+master_unit->uncacheable|=UNCACHEABLE_EXPLAIN;
+select_lex->uncacheable|= UNCACHEABLE_EXPLAIN;
if (!abort_on_null&& left_expr->maybe_null&& !pushed_cond_guards)
{
put space (' ') after '='
[skip]
___
commits mailing list
comm...@mariadb.org
https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 2935: Fixed LP bugs BUG#729067/730466. in file:///home/igor/maria/maria-5.3-bug729067/
Hi! Ok to push. 12 марта 2011, в 10:49, Igor Babaev написал(а): > At file:///home/igor/maria/maria-5.3-bug729067/ > > > revno: 2935 > revision-id: i...@askmonty.org-20110312084903-b9mmi2wdgbdar3tc > parent: tim...@askmonty.org-20110308212344-7r4ue17b3rxschlj > committer: Igor Babaev > branch nick: maria-5.3-bug729067 > timestamp: Sat 2011-03-12 00:49:03 -0800 > message: > Fixed LP bugs BUG#729067/730466. > Do not reset the value of the item_equal field in the Item_field object > once it has been set. > === modified file 'mysql-test/r/join.result' > --- a/mysql-test/r/join.result2011-02-28 21:29:59 + > +++ b/mysql-test/r/join.result2011-03-12 08:49:03 + > @@ -1285,3 +1285,38 @@ > 1 1 1 1 1 > 1 1 1 1 1 > drop table t1,t2,t3; > +# > +# BUG#729067/730466: unexpected 'Range checked for each record' > +#for queries with OR in WHERE clause > +# > +CREATE TABLE t1 (f1 int, f2 int) ; > +INSERT INTO t1 VALUES (4,0),(5,1); > +CREATE TABLE t2 (f1 int, f2 int, KEY (f2)) ; > +INSERT INTO t2 VALUES (5,7), (8,9); > +EXPLAIN > +SELECT * FROM t1 STRAIGHT_JOIN t2 ON t2.f1 = t1.f1 > +WHERE t1.f1<>0 OR t1.f2<>0 AND t1.f1 = t2.f2; > +id select_type table typepossible_keys key key_len ref > rowsExtra > +1SIMPLE t1 ALL NULLNULLNULLNULL2 Using > where > +1SIMPLE t2 ALL f2 NULLNULLNULL2 Using > where; Using join buffer (flat, BNL join) > +SELECT * FROM t1 STRAIGHT_JOIN t2 ON t2.f1 = t1.f1 > +WHERE t1.f1<>0 OR t1.f2<>0 AND t1.f1 = t2.f2; > +f1 f2 f1 f2 > +51 5 7 > +DROP TABLE t1,t2; > +CREATE TABLE t1(f1 int PRIMARY KEY, f2 int) ; > +INSERT INTO t1 VALUES (9,4), (10,9); > +CREATE TABLE t2(f1 int PRIMARY KEY, f2 int) ; > +INSERT INTO t2 VALUES (9,4), (10,9); > +EXPLAIN > +SELECT STRAIGHT_JOIN * FROM t1 JOIN t2 ON t2.f2 = t1.f1 > +WHERE t1.f1 IN (SELECT f1 FROM t1) AND t1.f1 = t2.f1 OR t1.f1 = 9; > +id select_type table typepossible_keys key key_len ref > rowsExtra > +1PRIMARY t1 ALL PRIMARY NULLNULLNULL2 Using > where > +1PRIMARY t2 ALL PRIMARY NULLNULLNULL2 Using > where; Using join buffer (flat, BNL join) > +2SUBQUERYt1 index NULLPRIMARY 4 NULL2 > Using index > +SELECT STRAIGHT_JOIN * FROM t1 JOIN t2 ON t2.f2 = t1.f1 > +WHERE t1.f1 IN (SELECT f1 FROM t1) AND t1.f1 = t2.f1 OR t1.f1 = 9; > +f1 f2 f1 f2 > +94 10 9 > +DROP TABLE t1,t2; > > === modified file 'mysql-test/t/join.test' > --- a/mysql-test/t/join.test 2011-02-28 21:29:59 + > +++ b/mysql-test/t/join.test 2011-03-12 08:49:03 + > @@ -964,3 +964,36 @@ > > drop table t1,t2,t3; > > +--echo # > +--echo # BUG#729067/730466: unexpected 'Range checked for each record' > +--echo #for queries with OR in WHERE clause > +--echo # > + > +CREATE TABLE t1 (f1 int, f2 int) ; > +INSERT INTO t1 VALUES (4,0),(5,1); > + > +CREATE TABLE t2 (f1 int, f2 int, KEY (f2)) ; > +INSERT INTO t2 VALUES (5,7), (8,9); > + > +EXPLAIN > +SELECT * FROM t1 STRAIGHT_JOIN t2 ON t2.f1 = t1.f1 > + WHERE t1.f1<>0 OR t1.f2<>0 AND t1.f1 = t2.f2; > +SELECT * FROM t1 STRAIGHT_JOIN t2 ON t2.f1 = t1.f1 > + WHERE t1.f1<>0 OR t1.f2<>0 AND t1.f1 = t2.f2; > + > +DROP TABLE t1,t2; > + > +CREATE TABLE t1(f1 int PRIMARY KEY, f2 int) ; > +INSERT INTO t1 VALUES (9,4), (10,9); > + > +CREATE TABLE t2(f1 int PRIMARY KEY, f2 int) ; > +INSERT INTO t2 VALUES (9,4), (10,9); > + > +EXPLAIN > +SELECT STRAIGHT_JOIN * FROM t1 JOIN t2 ON t2.f2 = t1.f1 > + WHERE t1.f1 IN (SELECT f1 FROM t1) AND t1.f1 = t2.f1 OR t1.f1 = 9; > +SELECT STRAIGHT_JOIN * FROM t1 JOIN t2 ON t2.f2 = t1.f1 > + WHERE t1.f1 IN (SELECT f1 FROM t1) AND t1.f1 = t2.f1 OR t1.f1 = 9; > + > +DROP TABLE t1,t2; > + > > === modified file 'sql/item_cmpfunc.cc' > --- a/sql/item_cmpfunc.cc 2011-02-06 04:57:03 + > +++ b/sql/item_cmpfunc.cc 2011-03-12 08:49:03 + > @@ -5723,7 +5723,8 @@ > not_null_tables_cache|= tmp_table_map; > if (item->maybe_null) > maybe_null=1; > -item->item_equal= this; > +if (!item->item_equal) > + item->item_equal= this; > } > fix_length_and_dec(); > fixed= 1; > > ___ > commits mailing list > comm...@mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB/MySQL error code issue
18 апр. 2011, в 12:40, Kristian Nielsen написал(а): > Hi, > > For merging MySQL into MariaDB, we need to work out what to do about error > code. > > The problem occurs as (different) new error messages are added in both MySQL > and MariaDB. When we then merge from MySQL, we get conflicts between the error > numbers. > > If we do not handle this somehow, it means that error numbers for a given > error message will be different, either between MySQL and MariaDB, or > alternatively between one version of MariaDB and another (depending on how > conflicts are resolved). > > The problem with error code changing is that this makes it much harder for > applications to check error codes and handle errors as it want in a portable > way between MySQL and MariaDB. > > I think we have these options: > > 1. Cooperate with MySQL@Oracle, so that whenever we add an error code in > MariaDB, the corresponding code is also reserved in MySQL (even if not used), > and vice versa. > > 2. Create different "namespaces" for error codes added to MariaDB and MySQL, > eg. new MariaDB codes are assigned with some offset to MySQL codes, so we > avoid conflicts. > > 3. Keep MariaDB error code numbers stable, re-assign MySQL error code numbers > when merging from MySQL (I rather dislike this as well because it introduces > incompatibility with MySQL). > > 4. Keep MySQL error code numbers when merging from MySQL, so that MariaDB-only > errors will fluctuate between releases (I really dislike this option). 5. Add interface of translation NAME <-> CODE as we do it for our test suite files where one can use ER_* names instead of numbers. I agre that it is might be not the best solution but I think it should be listed, because the name constants is something which we do not change but only add. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3077: Fixed LP bug #804686. in file:///home/igor/maria/maria-5.3-merge/
Hi! 04.07.2011 00:59, Igor Babaev пишет: At file:///home/igor/maria/maria-5.3-merge/ revno: 3077 revision-id: i...@askmonty.org-20110703215901-xmisn92l37tswlw8 parent: mo...@askmonty.org-20110702143759-sy79jwmahe66we7g committer: Igor Babaev branch nick: maria-5.3-merge timestamp: Sun 2011-07-03 14:59:01 -0700 message: Fixed LP bug #804686. The assert conditions in the functions Item_direct_ref_to_ident::transform and Item_direct_ref_to_ident::compile could be not valid after constant propagation when fields and field references may be substituted for constants. Not only these invalid asserts have been removed, but the functions containing them have been removed as well because now Item_ref::transform and Item_ref::compile can be used instead of them. The patch is OK. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3115: Fix bug lp:782305 in file:///home/tsk/mprog/src/5.3-work/
Hi! 18.07.2011 23:45, tim...@askmonty.org пишет: At file:///home/tsk/mprog/src/5.3-work/ revno: 3115 revision-id: tim...@askmonty.org-20110718204538-2976m25qh52g6l69 parent: i...@askmonty.org-20110717075207-sg6f40o1ps8mwxrj fixes bug(s): https://launchpad.net/bugs/782305 committer: tim...@askmonty.org branch nick: 5.3-work timestamp: Mon 2011-07-18 23:45:38 +0300 message: Fix bug lp:782305 Analysis: Both the wrong result and the valgrind warning were a result of incomplete cleanup of the MIN/MAX subquery rewrite. At the first execution of the query, the non-aggregate subquery is transformed into an aggregate MIN/MAX subquery. During the fix_fields phase of the MIN/MAX function, it sets the property st_select_lex::with_sum_func to true. The second execution of the query finds this flag to be ON. When optimization reaches the same MIN/MAX subquery transformation, it tests if the subquery is an aggregate or not. Since select_lex->with_sum_func == true from the previous execution, the transformation executes the second branch that handles aggregate subqueries. This substitutes the subquery Item into a Item_maxmin_subselect. At the same time elsewhere it is assumed that the subquery Item is of type Item_allany_subselect. Ultimately this results in casting the actual object to the wrong class, and calling the wrong any_value() method from empty_underlying_subquery(). Solution: Cleanup the st_select_lex::with_sum_func property in the case when the MIN/MAX transformation was performed for a non-aggregate subquery, so that the transformation can be repeated. The patch is OK. SUBS_MAXMIN_ENGINE is really good name, thank you! [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3138: Early check of subquery cache hit rate added to limit its performance impact in the worst case. in file:///home/bell/maria/bzr/work-maria-5.3-scache_impact/
Hi! 01.08.2011 10:12, Timour Katchaounov пишет: Sanja, Could you explain why these new constants are defines, and not declared const variables: === modified file 'sql/sql_expression_cache.cc' --- a/sql/sql_expression_cache.cc2011-07-28 14:10:29 + +++ b/sql/sql_expression_cache.cc2011-08-01 06:34:55 + @@ -26,6 +26,11 @@ hit_rate = hit / (miss + hit); */ #define EXPCACHE_MIN_HIT_RATE_FOR_MEM_TABLE 0.2 +/** + Number of cache miss to check hit ratio (maximum cache performance + impact in the case when the cache is not applicable) +*/ +#define EXPCACHE_EARLY_CHECK 200 All of these are potentially possible to tune, why make them compile-time defines? Heh, that is what I wanted to discuss. On one hand too many parameters is bad on other hand too simple is not good also... [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] ALL/ANY/IN and NULL/TRUE/FALSE tests
Hi! I checked the results according the link you gave me, also I thing the tests made compact enough. 20110901-subqueryNULLtest.diff Description: Binary data ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3182: BUG#833600: Wrong result with view + outer join + uncorrelated subquery (non-semijoin) in file:///home/psergey/dev2/5.3-push14/
Hi! 8 сент. 2011, в 22:24, Sergey Petrunya написал(а): > At file:///home/psergey/dev2/5.3-push14/ > > > revno: 3182 > revision-id: pser...@askmonty.org-20110908192447-h8rmi1gvivwh59eh > parent: pser...@askmonty.org-20110908173810-mcq7fj9d14ynyckq > committer: Sergey Petrunya > branch nick: 5.3-push14 > timestamp: Thu 2011-09-08 23:24:47 +0400 > message: > BUG#833600: Wrong result with view + outer join + uncorrelated subquery > (non-semijoin) > - The bug was caused by outer join being incorrectly converted into inner > because of >invalid return values of Item_direct_view_ref::not_null_tables(). > - Provided a correct Item_direct_view_ref::not_null_tables() function. The patch is OK [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3249: Fix of LP BUG#872775. in file:///home/bell/maria/bzr/work-maria-5.3-lpb872775/
25.10.2011 19:54, Sergei Petrunia пишет: On Tue, Oct 25, 2011 at 11:59:37AM +0300, sa...@askmonty.org wrote: At file:///home/bell/maria/bzr/work-maria-5.3-lpb872775/ revno: 3249 revision-id: sa...@askmonty.org-20111025085936-h0jyyxtbv3qhp4f4 parent: i...@askmonty.org-20111023124603-sjv665ajk25b4dgi committer: sa...@askmonty.org branch nick: work-maria-5.3-lpb872775 timestamp: Tue 2011-10-25 11:59:36 +0300 message: Fix of LP BUG#872775. The problem was that merged views has its own nest_level numbering => when we compare nest levels we should take into considiration basis (i.e. 0 level), if it is different then nest levels are not comparable. :grep nest_level_base *.h *.c* item.h|1165| st_select_lex_unit *nest_level_base; sql_lex.h|687| SELECT_LEX_UNIT *nest_level_base; /* unit from which we count nest_level */ item.cc|759| depended_from->nest_level_base == prm->nest_level_base&& item_subselect.cc|603| unit->first_select()->nest_level_base, item_sum.cc|363| ds->nest_level_base == prm->nest_level_base&& sql_lex.cc|342| lex->select_lex.nest_level_base=&lex->unit; sql_parse.cc|5920| select_lex->nest_level_base=&thd->lex->unit; The only places where nest_level_base is assigned are: sql_lex.cc|342| lex->select_lex.nest_level_base=&lex->unit; sql_parse.cc|5920| select_lex->nest_level_base=&thd->lex->unit; both of these initialize it to the top-level unit. So what is the point of having nest_level_base in this case? Please clarify :) It assign the top level UNIT (first for "main" SELECT, second for every other SELECT), but top level UNIT is different for main query and each view (each view parsed as separate SELECT with its own LEX and main UNIT and SELECT in it) [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3100: Fix gcc 4.6 warnings about assigned but not used variables. in file:///home/bell/maria/bzr/work-maria-5.1-applebuild/
26.10.2011 22:18, Michael Widenius пишет: Hi! "sanja" == sanja writes: sanja> At file:///home/bell/maria/bzr/work-maria-5.1-applebuild/ sanja> sanja> revno: 3100 sanja> revision-id: sa...@askmonty.org-20111025142424-dntpnipgi5qxg2io sanja> parent: w...@montyprogram.com-20111019185101-fw3oxkpr2o060qk4 sanja> committer: sa...@askmonty.org sanja> branch nick: work-maria-5.1-applebuild sanja> timestamp: Tue 2011-10-25 17:24:24 +0300 sanja> message: sanja>Fix gcc 4.6 warnings about assigned but not used variables. sanja>Fixed my_gethwaddr.c to allow compilation on Mac OS X. === modified file 'sql/sql_show.cc' --- a/sql/sql_show.cc 2011-05-12 11:56:08 + +++ b/sql/sql_show.cc 2011-10-25 14:24:24 + @@ -1215,7 +1215,7 @@ int store_create_info(THD *thd, TABLE_LI handler *file= table->file; TABLE_SHARE *share= table->s; HA_CREATE_INFO create_info; - bool show_table_options= FALSE; + bool show_table_options __attribute__ ((unused))= FALSE; bool foreign_db_mode= (thd->variables.sql_mode& (MODE_POSTGRESQL | MODE_ORACLE | MODE_MSSQL | Add instead: #ifdef WITH_PARTITION_STORAGE_ENGINE around the this the definition of the variable. This is what previous reviewer was against. And I think it was quite logical. Please settle it with serg. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3100: Fix gcc 4.6 warnings about assigned but not used variables. in file:///home/bell/maria/bzr/work-maria-5.1-applebuild/
26.10.2011 22:18, Michael Widenius пишет:
[skip]
=== modified file 'storage/pbxt/src/thread_xt.cc'
--- a/storage/pbxt/src/thread_xt.cc 2010-09-28 13:05:45 +
+++ b/storage/pbxt/src/thread_xt.cc 2011-10-25 14:24:24 +
@@ -485,7 +485,8 @@ static void thr_free_resources(XTThreadP
xtPublic void xt_bug(XTThreadPtr XT_UNUSED(self))
{
- static int *bug_ptr = NULL;
+ static int *bug_ptr __attribute__ ((unused));
+bug_ptr= NULL;
bug_ptr = NULL;
}
No reason to set this to null twice.
Better to remove the variable altogether.
Th code was super strange before, I left it strange :) I think it is
better to Percona to decide what to do with it (I sent them patch for 5.3).
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3100: Fix gcc 4.6 warnings about assigned but not used variables. in file:///home/bell/maria/bzr/work-maria-5.1-applebuild/
27.10.2011 15:29, Kristian Nielsen пишет:
Oleksandr Byelkin writes:
26.10.2011 22:18, Michael Widenius пишет:
[skip]
=== modified file 'storage/pbxt/src/thread_xt.cc'
--- a/storage/pbxt/src/thread_xt.cc 2010-09-28 13:05:45 +
+++ b/storage/pbxt/src/thread_xt.cc 2011-10-25 14:24:24 +
@@ -485,7 +485,8 @@ static void thr_free_resources(XTThreadP
xtPublic void xt_bug(XTThreadPtr XT_UNUSED(self))
{
- static int *bug_ptr = NULL;
+ static int *bug_ptr __attribute__ ((unused));
+bug_ptr= NULL;
bug_ptr = NULL;
}
Th code was super strange before, I left it strange :) I think it is
better to Percona to decide what to do with it (I sent them patch for
5.3).
Did you really send to Percona, or did you mean PBXT? Either way, PBXT it
should be :)
Actually I sent whole patch to percona hoping they will take part they want.
About pbxt - I was informed that nobody care about it, so did not do
special movement... In any case the patch is published and code was
preserved as it was :)
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3262: Fix bug lp:833702 in file:///home/tsk/mprog/src/5.3/
Hi! 01.11.2011 18:19, tim...@askmonty.org пишет: At file:///home/tsk/mprog/src/5.3/ revno: 3262 revision-id: tim...@askmonty.org-2001161919-hukh3tipjms3lfzf parent: sa...@askmonty.org-2001112209-n4ghsy9hpliiassm fixes bug(s): https://launchpad.net/bugs/833702 committer: tim...@askmonty.org branch nick: 5.3 timestamp: Tue 2011-11-01 18:19:19 +0200 message: Fix bug lp:833702 Analysis: Equality propagation propagated the constant '7' into args[0] of the Item_in_optimizer that stands for the "< ANY" predicate. At the same the min/max subquery rewrite swapped the order of the left and right operands of the "<" predicate, but used Item_in_subselect::left_expr. As a result, when the OK to push. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3276: Fix MySQL BUG#12329653 in file:///home/tsk/mprog/src/5.3/
Hi!
12 нояб. 2011, в 10:24, написал(а):
The patch is OK to push after one small change:
> At file:///home/tsk/mprog/src/5.3/
>
>
> revno: 3276
> revision-id: tim...@askmonty.org-2012082415-7t6jjzdfg35la7aq
> parent: i...@askmonty.org-2011225326-k11e0durn6kvivly
> committer: tim...@askmonty.org
> branch nick: 5.3
> timestamp: Sat 2011-11-12 10:24:15 +0200
> message:
> Fix MySQL BUG#12329653
>
> In MariaDB, when running in ONLY_FULL_GROUP_BY mode,
> the server produced in incorrect error message that there
> is an aggregate function without GROUP BY, for artificially
> created MIN/MAX functions during subquery MIN/MAX optimization.
>
> The fix introduces a way to distinguish between artifially
> created MIN/MAX functions as a result of a rewrite, and normal
> ones present in the query. The test for ONLY_FULL_GROUP_BY violation
> now tests in addition if a MIN/MAX function was part of a MIN/MAX
> subquery rewrite.
>
> In order to be able to distinguish these MIN/MAX functions, the
> patch introduces an additional flag in Item_in_subselect::in_strategy -
> SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its
> final choice of a subuqery strategy. In order to make the choice
> consistent, access to Item_in_subselect::in_strategy is provided
> via new class methods.
> **
> Fix MySQL BUG#12329653
>
> In MariaDB, when running in ONLY_FULL_GROUP_BY mode,
> the server produced in incorrect error message that there
> is an aggregate function without GROUP BY, for artificially
> created MIN/MAX functions during subquery MIN/MAX optimization.
>
> The fix introduces a way to distinguish between artifially
> created MIN/MAX functions as a result of a rewrite, and normal
> ones present in the query. The test for ONLY_FULL_GROUP_BY violation
> now tests in addition if a MIN/MAX function was part of a MIN/MAX
> subquery rewrite.
>
> In order to be able to distinguish these MIN/MAX functions, the
> patch introduces an additional flag in Item_in_subselect::in_strategy -
> SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its
> final choice of a subuqery strategy. In order to make the choice
> consistent, access to Item_in_subselect::in_strategy is provided
> via new class methods.
>
[skip]
> @@ -2606,9 +2606,8 @@ bool
> Item_allany_subselect::select_transformer(JOIN *join)
> {
> DBUG_ENTER("Item_allany_subselect::select_transformer");
> - DBUG_ASSERT((in_strategy & ~(SUBS_MAXMIN_INJECTED | SUBS_MAXMIN_ENGINE |
> - SUBS_IN_TO_EXISTS)) == 0);
> - in_strategy|= SUBS_IN_TO_EXISTS;
> +// DBUG_ASSERT((in_strategy & ~(SUBS_MAXMIN_INJECTED | SUBS_MAXMIN_ENGINE |
> +// SUBS_IN_TO_EXISTS)) == 0);
> if (upper_item)
> upper_item->show= 1;
> DBUG_RETURN(select_in_like_transformer(join));
> @@ -2617,7 +2616,7 @@ Item_allany_subselect::select_transforme
Remove the comment, but better change it to:
DBUG_ASSERT((in_strategy & ~(SUBS_MAXMIN_INJECTED | SUBS_MAXMIN_ENGINE |
SUBS_IN_TO_EXISTS | SUBS_STRATEGY_CHOSEN)) == 0);
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3322: Fixed bug lp:825051 in file:///home/tsk/mprog/src/5.3/
29.11.2011 23:06, tim...@askmonty.org пишет: At file:///home/tsk/mprog/src/5.3/ revno: 3322 revision-id: tim...@askmonty.org-2029210639-bjcn2pfocub6uwba parent: holyf...@askmonty.org-2029112752-6cy8wy7h5q58l6je fixes bug(s): https://launchpad.net/bugs/825051 committer: tim...@askmonty.org branch nick: 5.3 timestamp: Tue 2011-11-29 23:06:39 +0200 message: Fixed bug lp:825051 The cause of the wrong result was that Item_ref_null_helper::get_date() didn't use a method of the *_result() family, and fetched the data for the field from the current row instead of result_field. Changed to use the correct *_result() method, like to all other similar methods of Item_ref_null_helper. OK to push. Do not forget that we agreed to fix this typo in 5.2 at least. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3077: Fixed LP bug #904345. in file:///home/igor/maria/maria-5.2-bug904345/
Hi!
27.12.2011 20:46, Igor Babaev пишет:
At file:///home/igor/maria/maria-5.2-bug904345/
revno: 3077
revision-id: i...@askmonty.org-20111227184559-v7hlo1h98dz8ui32
parent: w...@montyprogram.com-20111223140257-k34gmwhs5msbc57k
committer: Igor Babaev
branch nick: maria-5.2-bug904345
timestamp: Tue 2011-12-27 10:45:59 -0800
message:
Fixed LP bug #904345.
The MIN/MAX optimizer code from the function opt_sum_query erroneously
did not take into account conjunctive conditions that did not depend on
any table, yet were not identified as constant items. These could be
items containing rand() or PS/SP parameters. These items are supposed
to be evaluated at the execution phase. That's why if such conditions
can be extracted from the WHERE condition the MIN/MAX optimization is
not applied as currently it is always done at the optimization phase.
(In 5.3 expensive subqueries are also evaluated only at the execution
phase. So, if a constant condition with such subquery can be extracted
from the WHERE clause the MIN/MAX optimization should not be applied
in 5.3.)
IF an IN/ALL/SOME predicate with a constant left part is transformed
into an EXISTS subquery the resulting subquery should not be considered
uncacheable if the right part of the predicate is not uncacheable.
Backported the function dbug_print_item() from 5.3. The function is used
only for debugging.
[skip]
=== modified file 'sql/item.cc'
--- a/sql/item.cc 2011-11-24 16:48:58 +
+++ b/sql/item.cc 2011-12-27 18:45:59 +
@@ -7915,6 +7915,22 @@
((TABLE_LIST *)data)->hide_view_error(thd);
}
+/* Debugger help function */
+static char dbug_item_print_buf[256];
+
+const char *dbug_print_item(Item *item)
+{
+ char *buf= dbug_item_print_buf;
+ String str(buf, sizeof(dbug_item_print_buf),&my_charset_bin);
+ str.length(0);
+ if (!item)
+return "(Item*)NULL";
+ item->print(&str ,QT_ORDINARY);
+ if (str.c_ptr() == buf)
+return buf;
+ else
+return "Couldn't fit into buffer";
+}
This should be put under #ifndef DBUG_OFF
Everything else looks OK to be pushed.
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3551: MDEV-4612 SQ pushdown: Server crashes in make_join_statistics with materialization+semijoin, IN subqueries, constant table, impossible condition in file:///h
Hi! 11.06.2013 11:11, tim...@askmonty.org пишет: At file:///home/tsk/mprog/src/10.0-md83/ revno: 3551 revision-id: tim...@askmonty.org-20130611081135-rge7p00h8e9nhypj parent: tim...@askmonty.org-20130528122232-kisslvdw5vhrna0q fixes bug: https://mariadb.atlassian.net/browse/MDEV-4612 committer: tim...@askmonty.org branch nick: 10.0-md83 timestamp: Tue 2013-06-11 11:11:35 +0300 message: MDEV-4612 SQ pushdown: Server crashes in make_join_statistics with materialization+semijoin, IN subqueries, constant table, impossible condition Analysis: The subquery materialization execution method subselect_hash_sj_engine::exec() didn't restore thd->lex->current_select through all return paths. This was not a problem when the method is called during execution. When a subquery was executed during the optimization phase of the outer query, current_select remained to point to the wrong subquery. This resulted in update_ref_and_keys() getting the wrong number of conditions via thd->lex->current_select->cond_count, thus allocating a smaller buffer for sargable conditions. This later resulted in memory overwrite. Solution: Make sure that subselect_hash_sj_engine::exec() always restores current_select. The patch looks OK to push. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] query cache issue
18.06.2013 04:16, Roberto Spadim пишет: guys, i sent some (many) MDEV issues to have a better control over query cache i want to comment here to don't stay with this idea in my mind only... i created some labels in JIRA: [skip] querycache_client - relative to implement query cache at client side (not in server) It is just interesting how QC can be connected to client side at all? [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] query cache issue
25.06.2013 16:58, Roberto Spadim пишет:
it's a memory in client side with query_parameters (sql_mode, query text,
schema used, and others flags that change results) + query_results
example in php
$query_cache= array(
"sql_mode=12341234124124;SELECT * from query_Table" => array(
"tables_used"=>array("query_Table"),
0=>array('a'=>1,'b'=>2,'c'=>3),
2=>array('a'=>1,'b'=>2,'c'=>3),
3=>array('a'=>1,'b'=>2,'c'=>3),
4=>array('a'=>1,'b'=>2,'c'=>3),
)
);
$query_tables_checksum=array("query_Table"=>'some_checksum');
the query_table_checksum is the part of query cache to invalidade a query
at client side, it must be checked at each query execution (this can be
done in less time or near time of a cached query)
before get from client side cache, query the server about table changes, if
the counter (or a checksum?)
if different, the query is invalid and must be removed from client side and
reexecuted, if not just get from query cache (in client side)
this add two news function at mysql protocol (one to get table
counters/checksums), and maybe must add a table counter that changes after
each update/delete/alter and save it (probably) at .FRM file, the other to
return the checksum at each query (with this we can see tables used in a
update for example and invalid the cache)
Query cache is certain feature of the server which is completely
transparent for the client side (and should be). What you written above
_COULD_ be other cache and so should be called with other name to avoid
confusion.
Please do not create confusion and mess in JIRA.
P.S.: BTW sql_mode & Co are stored on server side and only that data
does matter for the server response (JFYI).
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] query cache issue
26.06.2013 18:08, Roberto Spadim пишет: Nice, in this case, should be nice implement a cache server, and mysql servers will send cache to it? something like: 5 mysql clients (no cache here) < - >10 mysql servers (100mb of cache each) < - >2 cache servers (16gb of cache each) we could use local cache + remote cache, for example, with this the local cache will be very fast, and the remote cache will have a network delay (but it's faster than disk i/o) what you think? I think it is irrelevant to query cache. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Warning in dynamic columns code
Hi! 07.07.2013 12:37, Sergei Petrunia пишет: Hi Sanja, I have been seeing this warning on a number of platforms: 10.0-monty/sql/item_strfunc.cc: In member function ‘virtual bool Item_func_dyncol_create::fix_fields(THD*, Item**)’: 10.0-monty/sql/item_strfunc.cc:3887: warning: suggest a space before ‘;’ or explicit braces around empty body in ‘for’ statement I assume it is harmless, but just in case, passing it over to you. Could you please check it and get rid of it? Hopefully I have it fixed (my compiler do not show warning here so I could only guess). ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Help about patchs in mariadb - jira and lauchpad url
Hi! 18.07.2013 18:04, Roberto Spadim пишет: Hi guys, where patchs are commited in mariadb? for example this one: https://mariadb.atlassian.net/browse/MDEV-617 it don't have a link to any patch, there's a link to any lauchpad code? The test suite you can find in the e-mail with subject: [Commits] Rev 3636: MDEV-617 LP:671189 - Query cache is not used for tables or databases with dots in their names in file:///home/bell/maria/bzr/work-maria-10.0-monty/ Thu 2013-07-18 12:35:00 +0300 The fix was merged to the tree from 5.6 by me (committed by Monty), then fixed by Monty. Code you can find in 10.0-monty tree. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3772: MDEV-4645: Incorrect reads of frozen binlog events; FDE corrupted in relay log in file:///home/bell/maria/bzr/work-maria-10.0-MDEV-4548/
18.07.2013 19:39, Jeremy Cole пишет:
Sanja,
Re: https://mariadb.atlassian.net/browse/MDEV-4645
Re: http://lists.askmonty.org/pipermail/commits/2013-July/005093.html
I saw your commit on the commits list (sorry, wasn't on the list before the
mail went out, so I can't reply directly to that message).
A couple of points related to the commit:
- You seem to have an error in the get_header_len, as it's implemented
only in the base class, and you've left functions with the correct
signature for it but the wrong names in the two frozen classes (they were
left named has_fixed_minimal_header). This would mean the change is
completely broken. :)
- The change to get_header_len I think is in general fine, although it
does alter the point of the whole thing -- there is again no way to exactly
identify which events have frozen headers, programmatically (i.e. you can't
differentiate them from events who just "happen" to have header_len =
LOG_EVENT_MINIMAL_HEADER_LEN). I think that doesn't matter for this
patch, but does defeat the point of what I was trying to add.
- I don't really understand why you've made the hex printing code so
complex and completely unreadable (IMHO). This is not performance-sensitive
code and in my opinion should favor readability over performance. All you
seem to have saved in this change is to avoid printing some static
formatting characters ("#", "|", spaces, etc.) inside the loop. However, I
can hardly even figure out what it's supposed to be doing now.
- Additionally, you've changed the output slightly -- normally the ASCII
character section prints its ending "|" immediately after the last
character; it seems now to be fixed position (leaving extra spaces before
"|". This differs from the output of hexdump, and it somewhat
ambiguous/confusing.
- You've mixed tabs and spaces. :(
Thank you a lot for this bug-report, I saw that the test suite do not
cover the bug so did not pushed the fix hoping for your response.
Test suite still highly appreciated :) (if it is possible to make it at
all, I doubts)
The cause of changes was:
1) avoid double copying string (formatting characters are not really
matter) and extra memory allocation on the stack.
2) avoid 'if' in case when method can return value which we can use
directly (looks better IMHO)
3) avoid extra virtual method call (they are quite expensive)
Yes 1 and 3 are about performance but I deal with server code mostly.
I'll change the patch, thank you yet another time.
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Help about patchs in mariadb - jira and lauchpad url
Hi! 18.07.2013 20:54, Roberto Spadim пишет: nice, the email was send from what email? i receive maria-developers and maria-discussion, any other important commit email list? http://lists.askmonty.org/pipermail/commits/2013-July/005101.html From my e-mail ( sa...@montyprogram.com ) to comm...@mariadb.org [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3772: MDEV-4645: Incorrect reads of frozen binlog events; FDE corrupted in relay log in file:///home/bell/maria/bzr/work-maria-10.0-MDEV-4548/
Hi, Jeremy! 18.07.2013 21:12, Jeremy Cole пишет: Sanja, I could provide some very simple binary logs (from Google MySQL 5.1) which are internally consistent and have extra headers (they would have 31-byte headers instead of the usual 19-byte ones). That can at least pretty easily be used to make sure mysqlbinlog can parse them properly. I'd really appreciate it. (I have no such big experience with the logs to get some ones easy). ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3772: MDEV-4645: Incorrect reads of frozen binlog events; FDE corrupted in relay log in file:///home/bell/maria/bzr/work-maria-10.0-MDEV-4548/
Hi, Jeremy! 18.07.2013 19:39, Jeremy Cole пишет: [skip] - You've mixed tabs and spaces. :( The problem is that I do not see any \t printed. so where is that tabs you are talking about? [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] RFC: Compile-time checking for unmatched DBUG_ENTER/LEAVE via unused variable
20.07.2013 00:48, Jeremy Cole пишет: Maria developers/captains, Prior to posing it as a final patch contribution or opening a JIRA ticket, I wanted to propose this idea. The attached patch adds what amounts to compile-time checking for unmatched DBUG_ENTER/DBUG_LEAVE (DBUG_RETURN, DBUG_VOID_RETURN) by introducing a variable in DBUG_ENTER which is only used in DBUG_LEAVE. This allows any compiler which can robustly detect unused variables to detect the mismatch at compile-time. There is already a run-time check for this case, but it is somewhat limited as it requires _db_return_ to be called in order to detect the mismatch, and this is in practice not always the case. Particularly three cases allow this to escape detection: I like the idea. People who are responsible for DBUG_* are on vacation I hope they will like the patch too. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] RFC - query cache insert
05.08.2013 18:05, Roberto Spadim пишет: Hi guys! I was reading (again) the query cache source code of 10.0.3 ... please tell me if i understood right when we insert at query cache... thread put a lock in query cache (no one can result from query cache) thread read all data and write to network (caching the result to query cache) after end of thread real the query cache is unlocked.. my doubts are... what happen if the query is too slow? the query cache is disabled while executing the query? what happen if two equal queries (same SELECT) execute? the first one is locked until the second one end the query and get the result from query cache? or the first lock query cache and the second runs without query cache? You are wrong. Lock put only to register the query, then it will be unlocked and it is not connected to time of query executed. QC could be disabled during query execution and even situation when two same queries processed in the same time was taken into consideration and works properly. Also we put lock when write result to the cache (when intercept network output), again the lock time do not depend on query execution time. the last one there's any query cache changes in mind? i was reading the sql_cache.cc of old mysql servers and there's a todo list (very old i think) that didn't changed from old mysql to today mariadb 10.0.3, this todo list is inside mysql bug tracker? or mariadb jira? There are some QC changes planed (to make it more lock free for big (in terms of load) MariaDB database and you can find the task in Jira https://mariadb.atlassian.net/browse/MDEV-4454 [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] RFC - query cache insert
06.08.2013 20:49, Roberto Spadim пишет: humm i will check the source and understand how it is done, thanks oleksandr! but... another doubt... today query cache have: query blocks (with query and flags), table blocks (with tables) result blocks (with results) there's any way of two query blocks (or more) link to same result block? If it would be inexpensive way to detect query with same semantic why do not put them as one query? Why all that complications with linking the same result (and same tables BTW)? But there is no inexpensive way to detect it (re-printing query is quite expensive if we will do it for each query). I hope it explain everything. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] RFC - query cache insert
07.08.2013 18:44, Roberto Spadim пишет: Hi Oleksandr! humm i will check the source and understand how it is done, thanks oleksandr! but... another doubt... today query cache have: query blocks (with query and flags), table blocks (with tables) result blocks (with results) there's any way of two query blocks (or more) link to same result block? If it would be inexpensive way to detect query with same semantic why do not put them as one query? Why all that complications with linking the same result (and same tables BTW)? hum, are you talking about rewrite the source of queries (applications)? i think it's more complicate for some closed applications, i'm not thinking like a application developer now, i'm thinking like a dba. about links... that's how query cache works today, or not? at least three kind of blocks, one for queries and flags other for table and other for results, that's how qc_info plugin works at least about a new kind of blocks... 'raw' query will not be the same of a 'normalized' query (at most cases at least) I think separated blocks for each kind of query is nice, and allow a faster query hit for parser (expend less time at parsers qc hit)... Sorry I did not understand above, but it is not important (see below). But there is no inexpensive way to detect it (re-printing query is quite expensive if we will do it for each query). I hope it explain everything. yes it is expensive, but the idea isn't execute for each query, the "first version" will do it for every query (no problem), after some tunes could allow to enable / disable this cost, example the query size (number of bytes in query) number of truples (i don't remember the name, but that's the "field operator field" in WHERE and HAVING clauses number of tables, time expend in parser, or a SQL_CACHE_EXTENDED option to force a cache (in this case will only work for new applications) i didn't checked the time/cpu expend with rewriting queries (i didn't found this in source yet, but with time is will find), the numbers that i have are: 1)query cache hit is < 0,1ms for a query cache with more than 1 queries and a relative small database with 300qps (queries per second) 2)query execution is more than >1ms in many disks (with some buffer / cache it is faster) if rewrite is near 1ms, i think that's ok in some kind of workloads (a database with 1qps maybe isn't good), but again, 1ms is better than reading disk... There is other big flaw in your idea. When we return result from QC we do it _BEFORE_ parsing (and it is the QC huge advantage), so it is impossible to print the query in unified form. To do it we should parse it. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3772: MDEV-4645: Incorrect reads of frozen binlog events; FDE corrupted in relay log in file:///home/bell/maria/bzr/work-maria-10.0-MDEV-4548/
Hi, Jeremy! 07.08.2013 23:58, Jeremy Cole пишет: I meant that the code itself is sometimes indented with spaces, and sometimes tabs, not that you have printed with a mix of " " and "\t". That is because of setup of my editor according to MySQL codding style, it just do not use tabs at all (but lets tabs stay) [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3772: MDEV-4645: Incorrect reads of frozen binlog events; FDE corrupted in relay log in file:///home/bell/maria/bzr/work-maria-10.0-MDEV-4548/
07.08.2013 23:57, Jeremy Cole пишет: Sanja, (Resending with the mailing list since this previous conversation was there.) Thank you a lot! [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] RFC - query cache insert
Hi! 08.08.2013 08:05, Roberto Spadim пишет: hum... check if i'm thinking wrong about the internal flow of mariadb/mysql ... client send data over network server receive data server process data and check that it's a query command server check query cache and return if found (that's how query cache execute today, right?) (here no query was found in query cache) server parse/optimize the query (here where i want to include the 'normalized' query cache) server execute the query server send result to client (caching to query cache when possible) server end query command It could be put just after parsing (you do not need optimize). But again, it is huge overhead (in this schema query should be checked twice) and one should have very very high hit-rate of differently written but the same by semantic queries to get gain from it. So it is idea for very specific load which we can't meet in "wild nature". ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] RFC - query cache insert
08.08.2013 09:11, Roberto Spadim пишет: ops... i forgot one more question that i don't know how today it is executed... the "explain extended" create the "normalized query" after parse/optimize but don't execute the query, i'm thinking right or i miss something? Yes it could execute only constant expression if they are relatively cheap. But again there is no a lot of cases which makes the schema "profitable" (actually I hardly believe that there is at least one real world installation which require it (if you get optimization involved especially)). ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3552: Fix bug MDEV-4648 SQ pushdown: Wrong result (missing rows) with materialization+semijoin, IN and ALL subqueries, UNION in file:///home/tsk/mprog/src/10.0-md8
09.08.2013 14:30, tim...@askmonty.org пишет: At file:///home/tsk/mprog/src/10.0-md83/ revno: 3552 revision-id: tim...@askmonty.org-20130809113013-ia2f7zzw3mv3in7u parent: tim...@askmonty.org-20130611081135-rge7p00h8e9nhypj fixes bug: https://mariadb.atlassian.net/browse/MDEV-4648 committer: tim...@askmonty.org branch nick: 10.0-md83 timestamp: Fri 2013-08-09 14:30:13 +0300 message: Fix bug MDEV-4648 SQ pushdown: Wrong result (missing rows) with materialization+semijoin, IN and ALL subqueries, UNION (part of MDEV-83) Analysis: The cause of the wrong result was that the ALL subquery was incorrectly attached to the last table in the join plan . The ALL subquery was transformed into a MIN expression, however it still depended on OUTER_REF_TABLE_BIT as if it was a subquery. The reason for this dependence was that the transformed MIN expression referred to the Item_cache object of the left subquery operand created for the initial Item_in_optimizer. Solution: When transforming an ALL subquery into a MIN/MAX expression, use the actual left argument expression, instead of the Item_cache created for the subquery. OK to push. Thank you! ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] RFC - query cache using storage engine
Hi, Roberto! 15.08.2013 08:25, Roberto Spadim пишет: Hi guys, i was thinking about ideas for query cache... there's an mdev about partitioning query cache ( https://mariadb.atlassian.net/browse/MDEV-4454) instead of this, why not use a HEAP storage engine (with partitioning), or maybe a myisam or aria or innodb as "backend", and write a "frontend" (query cache) that execute commands over this storage engine? i'm talking about, changing the query/table/result blocks of query cache, to query/table/result tables when start mysqld truncate these tables when add new query "insert" to these tables when a table prune occur, "delete" from these tables when flush, optimize these tables when reset query cache, truncate this tables these tables could be at mysql schema, if they don't exists create as ENGINE=MEMORY for example since we must have a MAX SIZE for query cache, we could add a MAX SIZE for HEAP engine and a LOW MEMORY algorithm ( https://mariadb.atlassian.net/browse/MDEV-4675) at high level, what you think about this idea? What do you thing is a bottleneck of QC which we are trying to avoid with partitioning? [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Fwd: [Commits] Rev 3674: MDEV-4645: Incorrect reads of frozen binlog events; FDE corrupted in relay log in file:///home/bell/maria/bzr/work-maria-10.0-base-MDEV-4645/
15.08.2013 11:35, Kristian Nielsen пишет: Oleksandr Byelkin writes: Could you review this? (it is https://mariadb.atlassian.net/browse/MDEV-4645 ) Ok, but it will be at least a couple more days before I will have time to start. If urgent, you can also ask Sergei Golubchik, IIRC this is the patch from Jeremy Cole that he asked me about, and I already looked at once and accepted the general idea? No it is not a super urgent. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] regexp review
Hi! Hi! Everything is OK. But there are some small issues: --- mysql-test/include/ctype_utf8mb4.inc 2010-03-05 08:17:19 + +++ mysql-test/include/ctype_utf8mb4.inc2013-09-26 14:02:17 + @@ -234,15 +234,15 @@ set names utf8mb4; set names utf8mb4; # This should return TRUE -select 'вася' rlike '[[:<:]]вася[[:>:]]'; -select 'вася ' rlike '[[:<:]]вася[[:>:]]'; -select ' вася' rlike '[[:<:]]вася[[:>:]]'; -select ' вася ' rlike '[[:<:]]вася[[:>:]]'; +select 'вася' rlike '\\bвася\\b'; +select 'вася ' rlike '\\bвася\\b'; +select ' вася' rlike '\\bвася\\b'; +select ' вася ' rlike '\\bвася\\b'; Is above unsupported pattern? === modified file 'sql/mysqld.cc' --- sql/mysqld.cc2013-09-18 11:07:31 + +++ sql/mysqld.cc2013-09-26 14:02:17 + @@ -1898,7 +1898,7 @@ void clean_up(bool print_message) delete global_rpl_filter; end_ssl(); vio_end(); - my_regex_end(); + //my_regex_end(); #if defined(ENABLED_DEBUG_SYNC) /* End the debug sync facility. See debug_sync.cc. */ debug_sync_end(); @@ -3904,10 +3904,10 @@ static int init_common_variables() return 1; item_init(); #ifndef EMBEDDED_LIBRARY - my_regex_init(&my_charset_latin1, check_enough_stack_size); + //my_regex_init(&my_charset_latin1, check_enough_stack_size); my_string_stack_guard= check_enough_stack_size; #else - my_regex_init(&my_charset_latin1, NULL); + //my_regex_init(&my_charset_latin1, NULL); #endif /* Process a comma-separated character set list and choose Remove it please (I think it was just forgotten). ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Rev 3847: Client attributes
02.10.2013 18:13, Sergei Golubchik пишет:
Hi, Sanja!
On Oct 02, sa...@askmonty.org wrote:
=== modified file 'client/mysqltest.cc'
--- a/client/mysqltest.cc 2013-07-21 14:39:19 +
+++ b/client/mysqltest.cc 2013-10-02 13:54:55 +
@@ -5648,6 +5648,10 @@ void safe_connect(MYSQL* mysql, const ch
verbose_msg("Connecting to server %s:%d (socket %s) as '%s'"
", connection '%s', attempt %d ...",
host, port, sock, user, name, failed_attempts);
+
+ mysql_options(mysql, MYSQL_OPT_CONNECT_ATTR_RESET, 0);
+ mysql_options4(mysql, MYSQL_OPT_CONNECT_ATTR_ADD,
+ "program_name", "mysqltest");
Did you test connecting without connection attributes?
e.g. 5.5 client and 10.0 server?
and mysql-5.5 client? And mysql-5.6 client?
please do, at least manually
I tested it works (attributes are compatible and if they are not
supported it does not prevent other functions).
while(!mysql_real_connect(mysql, host,user, pass, db, port, sock,
CLIENT_MULTI_STATEMENTS |
CLIENT_REMEMBER_OPTIONS))
{
=== modified file 'include/mysql.h'
--- a/include/mysql.h 2013-07-18 14:46:57 +
+++ b/include/mysql.h 2013-10-02 13:54:55 +
@@ -557,6 +557,8 @@ int STDCALL mysql_list_proce
int status);
int STDCALL mysql_options(MYSQL *mysql,enum mysql_option option,
const void *arg);
+int STDCALL mysql_options4(MYSQL *mysql,enum mysql_option option,
+ const void *arg1, const void *arg2);
This is pretty silly, I'd rather have
mysql_optionv(MYSQL *mysql, enum mysql_option option, ...)
or even (redefining the existing function):
mysql_option(MYSQL *mysql, enum mysql_option option, ...)
but we're copying MySQL here, so we don't have much of a choice
void STDCALL mysql_free_result(MYSQL_RES *result);
int STDCALL mysql_free_result_start(MYSQL_RES *result);
int STDCALL mysql_free_result_cont(MYSQL_RES *result, int status);
=== modified file 'sql/sql_acl.cc'
--- a/sql/sql_acl.cc2013-09-21 08:14:42 +
+++ b/sql/sql_acl.cc2013-10-02 13:54:55 +
@@ -8570,7 +8628,13 @@ static ulong parse_client_handshake_pack
mpvio->acl_user->plugin= old_password_plugin_name;
}
}
-
+
+ if (db &&
Why do you check for db being not NULL?
removed and its works.
+ (thd->client_capabilities & CLIENT_CONNECT_ATTRS) &&
+ read_client_connect_attrs(&next_field, ((char *)net->read_pos) + pkt_len,
+mpvio->thd->charset()))
+return packet_error;
+
/*
if the acl_user needs a different plugin to authenticate
(specified in GRANT ... AUTHENTICATED VIA plugin_name ..)
=== modified file 'sql/sys_vars.cc'
--- a/sql/sys_vars.cc 2013-09-21 08:14:42 +
+++ b/sql/sys_vars.cc 2013-10-02 13:54:55 +
@@ -71,6 +71,7 @@
#define export /* not static */
#ifdef WITH_PERFSCHEMA_STORAGE_ENGINE
+#ifndef EMBEDDED_LIBRARY
Why is this?
removed (it actually caused bug)
The big question is if embedded does not support performance schema
should we remove all performance schema control variables?
static Sys_var_mybool Sys_pfs_enabled(
"performance_schema",
Regards,
Sergei
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Rev 3847: Client attributes
Hi! 03.10.2013 18:47, Sergei Golubchik пишет: Hi, Oleksandr! On Oct 03, Oleksandr Byelkin wrote: === modified file 'sql/sys_vars.cc' --- a/sql/sys_vars.cc 2013-09-21 08:14:42 + +++ b/sql/sys_vars.cc 2013-10-02 13:54:55 + @@ -71,6 +71,7 @@ #define export /* not static */ #ifdef WITH_PERFSCHEMA_STORAGE_ENGINE +#ifndef EMBEDDED_LIBRARY Why is this? removed (it actually caused bug) The big question is if embedded does not support performance schema should we remove all performance schema control variables? Not in this task. Naturally, it is not this task. But it is not clear from the answer, should they be removed or should not. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3702: Fixed bug mdev-5105. in file:///home/igor/maria/maria-5.3-mdev5105/
Hi! 10.10.2013 20:08, Igor Babaev пишет: At file:///home/igor/maria/maria-5.3-mdev5105/ revno: 3702 revision-id: i...@askmonty.org-20131010170826-dl2xwc048hvnxmau parent: i...@askmonty.org-20131004165107-0hdknrn9111ojupx committer: Igor Babaev branch nick: maria-5.3-mdev5105 timestamp: Thu 2013-10-10 10:08:26 -0700 message: Fixed bug mdev-5105. The bug caused a memory overwrite in the function update_ref_and_keys() It happened due to a wrong value of SELECT_LEX::cond_count. This value historically was calculated by the fix_fields method. Now the logic of calling this method became too complicated and, as a result, this value is calculated not always correctly. The patch changes the way how and when the values of SELECT_LEX::cond_count and of SELECT_LEX::between_count are calculated. The new code does it just at the beginning of update_ref_and_keys(). OK to push. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB made be compiled by gcc 4.8.1
Hi, Sergei!
23.10.2013 20:03, Sergei Golubchik пишет:
Hi, Sanja!
See below
On Oct 22, sa...@montyprogram.com wrote:
message:
MariaDB made be compiled by gcc 4.8.1
=== modified file 'extra/yassl/include/yassl_int.hpp'
--- a/extra/yassl/include/yassl_int.hpp 2012-04-05 08:49:38 +
+++ b/extra/yassl/include/yassl_int.hpp 2013-10-22 07:56:05 +
@@ -440,7 +440,7 @@ public:
const Ciphers&GetCiphers()const;
const DH_Parms& GetDH_Parms() const;
const Stats& GetStats() const;
-const VerifyCallback getVerifyCallback() const;
+VerifyCallback getVerifyCallback() const;
Why?
When I made this patch gcc was complaining that const for this type or
place is not appropriate (I do not remember now), but now it compile
normally with both changes about
getVerifyCallback reverted. So I'll make new patch (probably compiler was
updated since that time).
=== modified file 'storage/maria/ma_checksum.c'
--- a/storage/maria/ma_checksum.c 2008-04-03 13:40:25 +
+++ b/storage/maria/ma_checksum.c 2013-10-22 07:56:05 +
@@ -58,7 +58,7 @@ ha_checksum _ma_checksum(MARIA_HA *info,
length= _ma_calc_blob_length(blob_size_length, pos);
if (length)
{
-memcpy((char*) &pos, pos + blob_size_length, sizeof(char*));
+memcpy((char*) &pos, pos + blob_size_length, (sizeof(char*)));
Why?
ma_checksum.c: In function '_ma_checksum':
ma_checksum.c:61:60: error: argument to 'sizeof' in 'memcpy' call is the
same pointer type 'char *' as the destination; expected 'char' or an
explicit length [-Werror=sizeof-pointer-memaccess]
memcpy((char*) &pos, pos + blob_size_length, sizeof(char*));
^
BTW all other such fixes was done because this check.
crc= my_checksum(crc, pos, length);
}
continue;
Regards,
Sergei
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MariaDB made be compiled by gcc 4.8.1
24.10.2013 11:54, Sergei Golubchik пишет:
Hi, Sanja!
=== modified file 'storage/maria/ma_checksum.c'
--- a/storage/maria/ma_checksum.c 2008-04-03 13:40:25 +
+++ b/storage/maria/ma_checksum.c 2013-10-22 07:56:05 +
@@ -58,7 +58,7 @@ ha_checksum _ma_checksum(MARIA_HA *info,
length= _ma_calc_blob_length(blob_size_length, pos);
if (length)
{
-memcpy((char*) &pos, pos + blob_size_length, sizeof(char*));
+memcpy((char*) &pos, pos + blob_size_length, (sizeof(char*)));
Why?
ma_checksum.c: In function '_ma_checksum':
ma_checksum.c:61:60: error: argument to 'sizeof' in 'memcpy' call is the
same pointer type 'char *' as the destination; expected 'char' or an
explicit length [-Werror=sizeof-pointer-memaccess]
memcpy((char*) &pos, pos + blob_size_length, sizeof(char*));
^
shouldn't it be:
memcpy((char**) &pos, pos + blob_size_length, sizeof(char*));
Sanja ^^^
That would be a better fix. The result looks more logical than with
meaningless parentheses.
Or, I suppose, you can try to drop the cast completely:
memcpy(&pos, pos + blob_size_length, sizeof(pos));
Hehe, it was my first fix (remove casting). but then I thought that the
casting was done for something and decided do not touch it. If you think
that this way is better I'll do it.
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 3711: MDEV-5104 crash in Item_field::used_tables with broken order by in file:///home/tsk/mprog/src/5.3/
Hi! OK to push! Thank you! 29.10.2013 12:39, tim...@askmonty.org пишет: At file:///home/tsk/mprog/src/5.3/ revno: 3711 revision-id: tim...@askmonty.org-20131029103903-bvjnf3b2aqnoyut5 parent: sa...@askmonty.org-20131021104549-857lwynmy813qyd4 fixes bug: https://mariadb.atlassian.net/browse/MDEV-5104 committer: tim...@askmonty.org branch nick: 5.3 timestamp: Tue 2013-10-29 12:39:03 +0200 message: MDEV-5104 crash in Item_field::used_tables with broken order by Analysis: st_select_lex_unit::prepare() computes can_skip_order_by as TRUE. As a result join->prepare() gets called with order == NULL, and doesn't do name resolution for the inner ORDER clause. Due to this the prepare phase doesn't detect that the query references non-exiting function and field. Later join->optimize() calls update_used_tables() for a non-resolved Item_field, which understandably has no Field object. This call results in a crash. Solution: Resolve unnecessary ORDER BY clauses to detect if they reference non-exising objects. Then remove such clauses from the JOIN object. ___ commits mailing list comm...@mariadb.org https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] review of mdev-5095 (executing triggers on slave)
Hi!
03.12.2013 14:09, Michael Widenius пишет:
Hi!
Here is the review of mdev-5095
I got the diff from:
bzr diff -r3942..
[skip]
=== modified file 'sql/log_event.cc'
-#if !defined(MYSQL_CLIENT) && defined(HAVE_REPLICATION)
+#if defined(MYSQL_SERVER) && defined(HAVE_REPLICATION)
Was the above needed or mostly an optimization?
Actually above made to make headers and bodies of methods be controlled
by the same condition, because it is strange that header has one
condition and body different (now it means the same bt who know what it
will be in the future).
[skip]
@@ -8429,8 +8462,11 @@ int Rows_log_event::do_apply_event(Relay
*/
TABLE_LIST *ptr= rli->tables_to_lock;
for (uint i=0 ; ptr && (i < rli->tables_to_lock_count); ptr=
ptr->next_global, i++)
+{
const_cast(rli)->m_table_map.set_table(ptr->table_id,
ptr->table);
-
What does this test really do ?
(I was quickly checking the code to understand what m_table_id stands
for, but it was not obvious).
Following is passing flag about triggers on the server. The problem was
to pass it between table map event and row event. I do it via extended
TABLE_LIST (RPL_TABLE_LIST). but row event uses only TABLE so I need to
find somehow the corresponding TABLE_LIST.
+ if (m_table_id == ptr->table_id)
+master_had_triggers= ((RPL_TABLE_LIST*)ptr)->master_had_triggers;
if (table)
{
bool transactional_table= table->file->has_transactions();
@@ -8618,6 +8656,9 @@ int Rows_log_event::do_apply_event(Relay
*/
thd->reset_current_stmt_binlog_format_row();
thd->is_slave_error= 1;
+/* remove trigger's tables */
+if (slave_run_triggers_for_rbr)
+ restore_empty_query_table_list(thd->lex);
DBUG_RETURN(error);
}
You do the above 'restore_empty_query_table_list(thd->lex);' before
every return in this function, except the last return.
it is done before very last return but not so close to it.
- Isn't it better to do a 'error:' tag at the end of the function
to ensure we don't miss any cases ?
- Add a comment why we don't need to do this at the very end of
Rows_log_event::do_apply_event().
Something like:
/*
We don't have to call restore_empty_query_table_list() here as
it's called in rows_event_stmt_cleanup().
*/
When is lex->query_tables used?
the problem was that trigger procedures works only with
lex->query_tables (and it was one of the cause of skipping triggers in
row log events.
Is it only used by 'open' ?
It is where triggers processed (openng and locking tables).
If yes, isn't it enough to always reset it after the 'open' call?
We have a lot of ASSERTS that check the lists when we close tables. they
have the same problem with MERGE MYISAM tables and went this way I only
trying to do more or less the same.
@@ -9773,6 +9831,29 @@ Write_rows_log_event::do_before_row_oper
from the start.
*/
}
+ if (slave_run_triggers_for_rbr && !master_had_triggers && m_table->triggers )
+ {
+if (m_table->triggers->has_triggers(TRG_EVENT_DELETE,
+TRG_ACTION_AFTER))
+{
+ /*
+The table has AFTER DELETE triggers that might access to
+subject table and therefore might need delete to be done
+immediately. So we turn-off the batching.
+ */
+ (void) m_table->file->extra(HA_EXTRA_DELETE_CANNOT_BATCH);
+}
+if (m_table->triggers->has_triggers(TRG_EVENT_UPDATE,
+TRG_ACTION_AFTER))
+{
+ /*
+The table has AFTER UPDATE triggers that might access to subject
+table and therefore might need update to be done immediately.
+So we turn-off the batching.
+ */
+ (void) m_table->file->extra(HA_EXTRA_UPDATE_CANNOT_BATCH);
+}
+ }
Good that you noticed and fixed the above.
However, why not just call the function
prepare_triggers_for_insert_stmt()
that does exactly the same thing?
it also has table->mark_columns_needed_for_insert(); Raw log event mark
all columns in any case also checks some correspondence between real
columns on master & slave so I prefer do not interfere here.
@@ -10749,6 +10894,17 @@ Delete_rows_log_event::do_before_row_ope
*/
return 0;
}
+ if (slave_run_triggers_for_rbr && !master_had_triggers && m_table->triggers
&&
+ m_table->triggers->has_triggers(TRG_EVENT_DELETE,
+TRG_ACTION_AFTER))
+ {
+/*
+ The table has AFTER DELETE triggers that might access to subject table
+ and therefore might need delete to be done immediately. So we turn-off
+ the batching.
+*/
+(void) m_table->file->extra(HA_EXTRA_DELETE_CANNOT_BATCH);
+ }
Would be better if we could do a function 'prepare_triggers_for_delete_stmt()'
and use the same code here and in sql_delete.cc
maybe, but as I it will be temptation to put something more to the
function without noticing that
Re: [Maria-developers] [Commits] Rev 3732: Fixed bug mdev-5382 in file:///home/igor/maria/maria-5.3-mdev5382/
Hi! 05.12.2013 21:13, Igor Babaev пишет: At file:///home/igor/maria/maria-5.3-mdev5382/ revno: 3732 revision-id: i...@askmonty.org-20131205191320-pfja761po2x9p9ri parent: b...@mnogosearch.org-20131203110843-1bsdu0hcrpzhie8w committer: Igor Babaev branch nick: maria-5.3-mdev5382 timestamp: Thu 2013-12-05 11:13:20 -0800 message: Fixed bug mdev-5382 When marking used columns the function find_field_in_table_ref() erroneously called the walk method for the real item behind a view/derived table field with the second parameter set to TRUE. This erroneous code was introduced in 2006. OK to push! ___ commits mailing list comm...@mariadb.org https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] review of mdev-5095 (executing triggers on slave)
Hi!
10.12.2013 17:58, Michael Widenius пишет:
[skip]
+ if (m_table_id == ptr->table_id)
+master_had_triggers= ((RPL_TABLE_LIST*)ptr)->master_had_triggers;
if (table)
{
bool transactional_table= table->file->has_transactions();
@@ -8618,6 +8656,9 @@ int Rows_log_event::do_apply_event(Relay
*/
thd-> reset_current_stmt_binlog_format_row();
thd-> is_slave_error= 1;
+/* remove trigger's tables */
+if (slave_run_triggers_for_rbr)
+ restore_empty_query_table_list(thd->lex);
DBUG_RETURN(error);
}
You do the above 'restore_empty_query_table_list(thd->lex);' before
every return in this function, except the last return.
Oleksandr> it is done before very last return but not so close to it.
- Isn't it better to do a 'error:' tag at the end of the function
to ensure we don't miss any cases ?
- Add a comment why we don't need to do this at the very end of
Rows_log_event::do_apply_event().
Something like:
/*
We don't have to call restore_empty_query_table_list() here as
it's called in rows_event_stmt_cleanup().
*/
Did you do the above?
yes. (postreview patch)
[skip]
+ if (slave_run_triggers_for_rbr && !master_had_triggers && m_table->triggers
&&
+ m_table->triggers->has_triggers(TRG_EVENT_UPDATE,
+ TRG_ACTION_AFTER))
+ {
+/*
+ The table has AFTER UPDATE triggers that might access to subject
+ table and therefore might need update to be done immediately.
+ So we turn-off the batching.
+*/
+(void) m_table->file->extra(HA_EXTRA_UPDATE_CANNOT_BATCH);
+ }
+
Would be better if we could do a function 'prepare_triggers_for_update_stmt()'
and use the same code here and in sql_update.cc
Oleksandr> see above.
Agree with having this as a table function.
One last question:
Do you happen to know why we in select_create::prepare() call
table->mark_columns_needed_for_insert();
but not
prepare_triggers_for_insert_stmt() ?
Does this mean:
1) This is a bug, we should instead call prepare_triggers_for_insert_stmt().
2) prepare_triggers_for_insert_stmt() is called later
(and thus table->mark_columns_needed_for_insert() is called twice).
3) prepare_triggers_for_insert_stmt() is not needed in this case ???
My guess would be that we are calling mark_columns_needed_for_insert()
twice and we can delete one of the calls, probably in select_create::prepare(),
but I didn't have time to verify this.
I hope that I have understand the question correctly.
I checked mark_columns_needed_for_insert() it always called only once.
SELECT ... CREATE has no trigger preparation because there is no way to
get triggers on the table we are creating in the same statement.
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] Rev 4056: MDEV-5607: Query cache destroys uninitialized rwlock in file:///home/bell/maria/bzr/work-maria-5.5-MDEV-5607/
Hi, Sergey! 08.02.2014 18:50, Sergey Vojtovich пишет: Hi Sanja, JFYI: while reporting this bug I came up with two questions that I couldn't answer quickly. Probably they make sense, if not just ignore them: 1. This code was introduced with https://bugs.launchpad.net/maria/+bug/782223, revision: w...@montyprogram.com-20110514163720-rmico2qegtptjguk The callstack leading of "free" containing critical section is: mysqld!free my_no_flags_free Query_cache::free_cache Query_cache::resize fix_query_cache_size set_var::update sql_set_variables mysql_execute_command mysql_parse It means that this code was supposed to be executed exactly by Query_cache::resize(), where you disable it. Question: if this code is not supposed to be executed by ::resize(), is it needed at all? It makes some other things so probably it is needed (and as can see stack it was more about whole cache, but of course I can't revise head of Wlad :) 2. In Query_cache::resize() I can see block-level locks are acquired with the following comment: Wait for all readers and writers to exit. When the list of all queries is iterated over with a block level lock, we are done. Isn't it needed in ::free_cache() also? Free cache used in 1) init (it definitely do not need) 2) unlock with check that there is no requests (when switching cache off) 3) destruction here (as I think) all clients should be disconnected already because of server shutdown. 4) resize (but here you see that it was locked and unlocked [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Rev 4056: MDEV-5607: Query cache destroys uninitialized rwlock
10.02.2014 16:24, Sergei Golubchik пишет: Hi, Sanja! On Feb 08, sa...@askmonty.org wrote: revno: 4056 revision-id: sa...@askmonty.org-20140208132448-qdkkpdncnya0tr6j parent: ele...@wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 committer: sa...@askmonty.org branch nick: work-maria-5.5-MDEV-5607 timestamp: Sat 2014-02-08 15:24:48 +0200 message: MDEV-5607: Query cache destroys uninitialized rwlock - Resize destroyed rw_lock twice, now it is prevented. - Trash destroyed rw lock. === modified file 'include/mysql/psi/mysql_thread.h' --- a/include/mysql/psi/mysql_thread.h 2013-01-11 00:03:43 + +++ b/include/mysql/psi/mysql_thread.h 2014-02-08 13:24:48 + @@ -16,6 +16,8 @@ #ifndef MYSQL_THREAD_H #define MYSQL_THREAD_H +#include This is not ok. Files under include/mysql/ are Plugin API files, they should be clean from internal includes. You cannot include my_valgrind.h from there. Do it in my_pthread.h my_pthread is not suitable. In psi/mysql_thread defined wrapping class and in that class the double destruction is visible (first version was made as you recommended it my_pthread but it does not worked to reproduce the bug). I can use just memset() instead of TRASH(). ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 8bfc350: MDEV-10148: Database crashes in the query to the View
Hi, Sergei! On 12/16/2016 03:16 PM, Sergei Petrunia wrote: revision-id: 8bfc35041195b46c8f4666dd02f600e878f45643 parent(s): 96d2e0480ffbc36c803db5a7d5bcefd3470c5f72 committer: Sergei Petrunia branch nick: 5.5 timestamp: 2016-12-16 17:16:02 +0300 message: MDEV-10148: Database crashes in the query to the View Fix st_select_lex::is_merged_child_of to work across merged views or derived tables. OK to push! [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] How correctly allocate memory to avoid problems with 2nd execution (instruction)
Hi! It is for all who decide to write or already is writing something for server. There is 2 ways to execute query/statement: 1) conventional (one time) 2) with storing the statement and executing it many times (Prepared statements (PS)/ Stored Procedures(SP)) Also there is so called Query_arena, which is a MEM_ROOT and list of allocated Item-s in it. (we need list of items because they could require not trivial destruction/cleanup procedure before freeing memory, see cleanup() methods of Item-s) For conventional execution there is only one (run-time) query arena (part of THD in this case) where all memory allocated, and all Item-s linked. After execution Item-s cleaned up and memory freed. For case with stored statements (PS/SP) there is one Query_arena where Parsing result allocated (statement arena), and the other one so called run-time arena (which freed after execution as for conventional execution). During parsing statement arena is active (default), during all execution steps the run-time arena is active (if nothing changed it specially). So if some one decided allocate some memory during execution one should think if it is: I) only for execution II) should live with the statement All references on the memory allocated as case I) should be returned in the state as it was before execution or taken other measures to prevent using them during the next execution. All object which allocated as persistent (for statement of course) should be a) allocated only once (can be first execution or prepare phase, it does not matter, what does matter: do not make memory leak by allocating on each execution) b) reference on them should not be lost (because it supposed to be reused during next execution) c) procedure of allocation during run-time should looks like this: Query_arena *arena, backup; // backup run-time arena and set as default statement arena if needed // (if it is not conventional execution) arena= thd->activate_stmt_arena_if_needed(&backup);\ mem_root> // return old default arena if it was changed before if (arena) thd->restore_active_arena(arena, &backup); ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MDEV-10306 Wrong results with combination of CONCAT, SUBSTR and CONVERT in subquery
Hi! Am 01.03.2017 um 13:56 schrieb Sergei Golubchik: Hi, Alexander! On Feb 28, Alexander Barkov wrote: commit af8887b86ccbaea8782cf54fe445cf53aaef7c06 Author: Alexander Barkov Date: Tue Feb 28 10:28:09 2017 +0400 MDEV-10306 Wrong results with combination of CONCAT, SUBSTR and CONVERT in subquery The bug happens because of a combination of unfortunate circumstances: 1. Arguments args[0] and args[2] of Item_func_concat point recursively (through Item_direct_view_ref's) to the same Item_func_conv_charset. Both args[0]->args[0]->ref[0] and args[2]->args[0]->ref[0] refer to this Item_func_conv_charset. 2. When Item_func_concat::args[0]->val_str() is called, Item_func_conv_charset::val_str() writes its result to Item_func_conc_charset::tmp_value. 3. Then, for optimization purposes (to avoid copying), Item_func_substr::val_str() initializes Item_func_substr::tmp_value to point to the buffer fragment owned by Item_func_conv_charset::tmp_value Item_func_substr::tmp_value is returned as a result of Item_func_concat::args[0]->val_str(). 4. Due to optimization to avoid memory reallocs, Item_func_concat::val_str() remembers the result of args[0]->val_str() in "res" and further uses "res" to collect the return value. 5. When Item_func_concat::args[2]->val_str() is called, Item_func_conv_charset::tmp_value gets overwritten (see #1), which effectively overwrites args[0]'s Item_func_substr::tmp_value (see #3), which effectively overwrites "res" (see #4). The fix marks Item_func_substr::tmp_value as a constant string, which tells Item_func_concat::val_str "Don't use me as the return value, you cannot append to me because I'm pointing to a buffer owned by some other String". This pretty much looks like a hack, that makes the bug disappear in this particular test case. What if SUBSTR() wasn't used? CONCAT would still modify args[0]->tmp_value, and it would be overwritten by args[2]->val_str(). On the other hand, if you remove args[2] from the test case, then CONCAT can safely modify args[0]'s buffer and marking SUBSTR as const would prevent a valid optimization. So, I see few possible approaches to this and other similar queries: 1. We specify that no Item's val method can modify the buffer of the arguments. That is, CONCAT will always have to copy. SUBSTR won't need to copy, because it doesn't modify the buffer, it only returns a pointer into it. 2. May be #1 is not strict enough, and we'll need to disallow pointers into the arguments' buffer too. Because, perhaps, args[2]->val_str() could realloc and then the pointer will become invalid. IMHO 2 is most realistic and safe. I can imagine many situation when one item val_* called many times and have no idea how it easy can be avoided without major refactoring (it is about #3 & #4). 3. A different approach would be to disallow one item to appear twice in an expression. No idea how to do that. 4. A variand of #3, an item can appear many times, but it'll be only evaluated once per row. That still needs #1, but #2 is unnecessary. Opinions? Ideas? IMHO 2 is good idea (Actually I thought that now it is done like 2) Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MDEV-10306 Wrong results with combination of CONCAT, SUBSTR and CONVERT in subquery
Am 01.03.2017 um 15:04 schrieb Sergei Golubchik: Hi, Oleksandr! On Mar 01, Oleksandr Byelkin wrote: So, I see few possible approaches to this and other similar queries: 1. We specify that no Item's val method can modify the buffer of the arguments. That is, CONCAT will always have to copy. SUBSTR won't need to copy, because it doesn't modify the buffer, it only returns a pointer into it. 2. May be #1 is not strict enough, and we'll need to disallow pointers into the arguments' buffer too. Because, perhaps, args[2]->val_str() could realloc and then the pointer will become invalid. IMHO 2 is most realistic and safe. I can imagine many situation when one item val_* called many times and have no idea how it easy can be avoided without major refactoring (it is about #3 & #4). 3. A different approach would be to disallow one item to appear twice in an expression. No idea how to do that. 4. A variand of #3, an item can appear many times, but it'll be only evaluated once per row. That still needs #1, but #2 is unnecessary. Opinions? Ideas? IMHO 2 is good idea (Actually I thought that now it is done like 2) Well, sure. It's the bullet-proof one, but most expensive performance wise, many items will need to start copying the result, basically on every level of the expression tree the string will need to be copied. So I'd prefer we find something more light-weight. Actually val_str accept buffer and if we ensure that the buffer used each time is different and value stored in it changing it is not a problem at all, problem is that some Items do not use it in sake of the efficiency, so maybe we should go this direction? ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 23959479689: MDEV-11419: Report all INSERT ID for bulk operation INSERT
Hi, Sergei!
Here is better answer (I had time to dig in the sources)
Am 14.03.2017 um 12:27 schrieb Sergei Golubchik:
Hi, Oleksandr!
On Jan 17, Oleksandr Byelkin wrote:
revision-id: 23959479689f47bdfe5aa33cb6cd5e1171b5f8a8
(mariadb-10.2.2-128-g23959479689)
parent(s): 9ea5de30963dd16cec7190b8b2f77858f4a82545
committer: Oleksandr Byelkin
timestamp: 2017-01-17 15:47:17 +0100
message:
MDEV-11419: Report all INSERT ID for bulk operation INSERT
Send all Insert IDs of the buld operation to client (JDBC need it)
---
include/mysql.h.pp | 3 +-
include/mysql_com.h | 3 +-
sql/protocol.cc | 22 +++---
sql/protocol.h | 6 +++
sql/sql_class.cc| 116
sql/sql_class.h | 8
sql/sql_insert.cc | 11 -
sql/sql_prepare.cc | 21 --
Tests are in C/C repository, I hope?
We discussed it, will be the test.
diff --git a/include/mysql_com.h b/include/mysql_com.h
index c399520022d..9fac5edd1bc 100644
--- a/include/mysql_com.h
+++ b/include/mysql_com.h
@@ -551,7 +551,8 @@ enum enum_cursor_type
CURSOR_TYPE_NO_CURSOR= 0,
CURSOR_TYPE_READ_ONLY= 1,
CURSOR_TYPE_FOR_UPDATE= 2,
- CURSOR_TYPE_SCROLLABLE= 4
+ CURSOR_TYPE_SCROLLABLE= 4,
+ INSERT_ID_REQUEST= 128
That's very weird. Why would "INSERT_ID_REQUEST" be a flag in the
"cursor_type"?
Don't put this flag into enum_cursor_type
It is flags and it happened that they are about cursors, but field of
flags can be used for other flags also (IMHO)
};
diff --git a/sql/protocol.cc b/sql/protocol.cc
index f8b68c02fff..608c06da2df 100644
--- a/sql/protocol.cc
+++ b/sql/protocol.cc
@@ -562,6 +562,7 @@ void Protocol::end_statement()
switch (thd->get_stmt_da()->status()) {
case Diagnostics_area::DA_ERROR:
+thd->stop_collecting_insert_id();
/* The query failed, send error to log and abort bootstrap. */
error= send_error(thd->get_stmt_da()->sql_errno(),
thd->get_stmt_da()->message(),
@@ -573,12 +574,21 @@ void Protocol::end_statement()
break;
case Diagnostics_area::DA_OK:
case Diagnostics_area::DA_OK_BULK:
-error= send_ok(thd->server_status,
- thd->get_stmt_da()->statement_warn_count(),
- thd->get_stmt_da()->affected_rows(),
- thd->get_stmt_da()->last_insert_id(),
- thd->get_stmt_da()->message(),
- thd->get_stmt_da()->skip_flush());
+if (thd->report_collected_insert_id())
+ if (thd->is_error())
+error= send_error(thd->get_stmt_da()->sql_errno(),
+ thd->get_stmt_da()->message(),
+ thd->get_stmt_da()->get_sqlstate());
+ else
+error= send_eof(thd->server_status,
+thd->get_stmt_da()->statement_warn_count());
+else
+ error= send_ok(thd->server_status,
+ thd->get_stmt_da()->statement_warn_count(),
+ thd->get_stmt_da()->affected_rows(),
+ thd->get_stmt_da()->last_insert_id(),
+ thd->get_stmt_da()->message(),
+ thd->get_stmt_da()->skip_flush());
break;
case Diagnostics_area::DA_DISABLED:
break;
diff --git a/sql/protocol.h b/sql/protocol.h
index 6397e3dd5e6..bf74f52fa98 100644
--- a/sql/protocol.h
+++ b/sql/protocol.h
@@ -30,6 +30,12 @@ class Item_param;
typedef struct st_mysql_field MYSQL_FIELD;
typedef struct st_mysql_rows MYSQL_ROWS;
+struct insert_id_desc
+{
+ ulonglong first_id;
+ ulonglong sequence;
+};
+
class Protocol
{
protected:
diff --git a/sql/sql_class.cc b/sql/sql_class.cc
index 8fabc8f593e..53591c371c0 100644
--- a/sql/sql_class.cc
+++ b/sql/sql_class.cc
@@ -1474,6 +1474,7 @@ void THD::init(void)
#endif //EMBEDDED_LIBRARY
apc_target.init(&LOCK_thd_data);
+ insert_ids= NULL;
DBUG_VOID_RETURN;
}
@@ -7365,4 +7366,119 @@ bool Discrete_intervals_list::append(Discrete_interval *new_interval)
DBUG_RETURN(0);
}
+bool THD::init_collecting_insert_id()
+{
+ if (!insert_ids)
+ {
+void *buff;
+if (!(my_multi_malloc(MYF(MY_WME), &insert_ids, sizeof(DYNAMIC_ARRAY),
+ &buff, sizeof(insert_id_desc) * 10,
+ NullS)) ||
+my_init_dynamic_array2(insert_ids, sizeof(insert_id_desc),
+ buff, 10, 100, MYF(MY_WME)))
Huh?
1. You allocate DYNAMIC_ARRAY, on the heap, for every (insert-id
generating) statement. Why?
2. You preallocate a buffer, but dynamic array cannot reallocate it, so
on the 11'th element, it'll allocate *another* buffer and won't
use yours.
Better: put DYNAMIC_ARRAY in the THD, or (even better) allocate it with
thd->alloc. And let DYNA
Re: [Maria-developers] [External] Re: 23959479689: MDEV-11419: Report all INSERT ID for bulk operation INSERT
Hi, Jean-Francois! Am 14.03.2017 um 20:31 schrieb Jean-Francois B. Gagne: Hi Sergei and Oleksandr, if we implement this (MDEV-11419: Report all INSERT ID for bulk operation INSERT), does this mean that we could allow innodb_autoinc_lock_mode=2 and still be safe for SBR ? [1]: https://mariadb.com/kb/en/mariadb/auto_increment-handling-in-xtradbinnodb/ I answered from my phone, but not sure that it worked, so I'll repeat. The idea is to report IDs as if they reported by separate call of INSERT with each parameter, so EXECUTE INSERT with 5 parameters got back 5 IDs. The other variant is to all that command 5 times and get back 5 IDs via 5 server status report for each command. Array parameters binding return 1 status so it can report all IDs there. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MDEV-9217 Split Item::tmp_table_field_from_field_type() into virtual methods in Type_handler
Hi, Alexander! Am 23.04.2017 um 22:39 schrieb Alexander Barkov: Hello Sanja, Monty has pushed his patch changing Item::name and Field::field_name to LEX_CSTRING. I have adjusted my patch accordingly. On 04/21/2017 11:33 PM, Alexander Barkov wrote: Hello Sanja, I wrote extended commit comments for the patch, to make review easier. Please find attached. Thanks. On 04/21/2017 08:05 PM, Alexander Barkov wrote: Hello Sanja, Please review a patch for MDEV-9217. Thanks! OK to push, after changes of constant and running all tests. ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 01b2bb79bb78e42108e32af02f1418a660ca861d Fixed the bug mdev-13064.
Hi, Igor!
Am 15.06.2017 um 23:43 schrieb Igor Babaev:
commit 01b2bb79bb78e42108e32af02f1418a660ca861d
Author: Igor Babaev
Commit: Igor Babaev
Fixed the bug mdev-13064.
This is another attempt to fix the bug mdev-12992.
This patch introduces st_select_lex::context_analysis_place for
the place in SELECT where context analysis is currently performed.
It's similar to st_select_lex::parsing_place, but it is used at
It is OK to push.
the preparation stage.
---
mysql-test/r/func_group.result |9 +
mysql-test/t/func_group.test | 13 +
sql/item.cc|5 ++---
sql/item_windowfunc.cc |2 +-
sql/sql_lex.h |1 +
sql/sql_select.cc | 33 ++---
6 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/mysql-test/r/func_group.result b/mysql-test/r/func_group.result
index cb97ea2..c4e991e 100644
--- a/mysql-test/r/func_group.result
+++ b/mysql-test/r/func_group.result
@@ -2447,3 +2447,12 @@ DROP TABLE t1;
#
# End of 10.1 tests
#
+#
+# MDEV-13064: assertion `n < m_size' fails in Item::split_sum_func2()
+#
+create table t1 (i int) engine=MyISAM;
+insert into t1 value (1),(2);
+select count(*)+sleep(0) from t1;
+count(*)+sleep(0)
+2
+drop table t1;
diff --git a/mysql-test/t/func_group.test b/mysql-test/t/func_group.test
index 1e75099..8bbc9e6 100644
--- a/mysql-test/t/func_group.test
+++ b/mysql-test/t/func_group.test
@@ -1691,3 +1691,16 @@ DROP TABLE t1;
--echo #
--echo # End of 10.1 tests
--echo #
+
+--echo #
+--echo # MDEV-13064: assertion `n < m_size' fails in Item::split_sum_func2()
+--echo #
+
+create table t1 (i int) engine=MyISAM;
+insert into t1 value (1),(2);
+
+select count(*)+sleep(0) from t1;
+
+drop table t1;
+
+
diff --git a/sql/item.cc b/sql/item.cc
index 8db5cfc..df615b5 100644
--- a/sql/item.cc
+++ b/sql/item.cc
@@ -490,8 +490,7 @@ int Item::save_str_value_in_field(Field *field, String
*result)
command => we should check thd->lex->current_select on zero (thd->lex
can be uninitialised)
*/
- if (thd->lex->current_select &&
- thd->stmt_arena->is_stmt_prepare_or_first_sp_execute())
+ if (thd->lex->current_select)
{
enum_parsing_place place=
thd->lex->current_select->parsing_place;
@@ -5513,7 +5512,7 @@ bool Item_field::fix_fields(THD *thd, Item **reference)
SELECT_LEX *select= thd->lex->current_select;
thd->change_item_tree(reference,
- select->parsing_place == IN_GROUP_BY &&
+ select->context_analysis_place == IN_GROUP_BY
&&
alias_name_used ? *rf->ref : rf);
/*
diff --git a/sql/item_windowfunc.cc b/sql/item_windowfunc.cc
index 59a22c6..27b0072 100644
--- a/sql/item_windowfunc.cc
+++ b/sql/item_windowfunc.cc
@@ -71,7 +71,7 @@
{
DBUG_ASSERT(fixed == 0);
- enum_parsing_place place= thd->lex->current_select->parsing_place;
+ enum_parsing_place place= thd->lex->current_select->context_analysis_place;
if (!(place == SELECT_LIST || place == IN_ORDER_BY))
{
diff --git a/sql/sql_lex.h b/sql/sql_lex.h
index face3bc..0c55ffc 100644
--- a/sql/sql_lex.h
+++ b/sql/sql_lex.h
@@ -855,6 +855,7 @@ class st_select_lex: public st_select_lex_node
/* reserved for exists 2 in */
uint select_n_reserved;
enum_parsing_place parsing_place; /* where we are parsing expression */
+ enum_parsing_place context_analysis_place; /* where we are in prepare */
bool with_sum_func; /* sum function indicator */
ulong table_join_options;
diff --git a/sql/sql_select.cc b/sql/sql_select.cc
index 4c64cf2..6c56f01 100644
--- a/sql/sql_select.cc
+++ b/sql/sql_select.cc
@@ -648,17 +648,15 @@ void remove_redundant_subquery_clauses(st_select_lex
*subq_select_lex)
thd->lex->allow_sum_func|= (nesting_map)1 << select->nest_level;
- save_place= thd->lex->current_select->parsing_place;
- thd->lex->current_select->parsing_place= IN_ORDER_BY;
+ save_place= thd->lex->current_select->context_analysis_place;
+ thd->lex->current_select->context_analysis_place= IN_ORDER_BY;
res= res || setup_order(thd, ref_pointer_array, tables, fields, all_fields,
order);
- thd->lex->current_select->parsing_place= save_place;
- thd->lex->allow_sum_func&= ~((nesting_map)1 << select->nest_level);
- save_place= thd->lex->current_select->parsing_place;
- thd->lex->current_select->parsing_place= IN_GROUP_BY;
+ thd->lex->allow_sum_func&= ~((nesting_map)1 << select->nest_level);
+ thd->lex->current_select->context_analysis_place= IN_GROUP_BY;
res= res || setup_group(thd, ref_pointer_array, tables, fields, all_fields,
group, hidden_group_fields);
- thd->lex->current_select->parsing_place= save_place;
+ thd->lex->current_select->context_analysis_place= save_pl
Re: [Maria-developers] [Commits] 2d6649aa24c: MDEV-13186: main.win failure post MDEV-12336
Hi, Vicentiu!
Am 27.06.2017 um 11:31 schrieb vicentiu:
revision-id: 2d6649aa24c77321df349de5cee576dab1e344f4
(mariadb-10.2.6-55-g2d6649aa24c)
parent(s): c036d5ada7a5816d25915a2c6e0b6836b0cd6743
author: Vicențiu Ciorbaru
committer: Vicențiu Ciorbaru
timestamp: 2017-06-27 12:26:38 +0300
message:
MDEV-13186: main.win failure post MDEV-12336
During statement preparation st_order::item gets set to a value in
ref_ptr_array. During statement execution we were overriding that value,
causing subsequent checks for window functions to return true.
Whenever we do any setting from ref_ptr_array, make sure to always
store the value in all_fields as well.
For function items containing window functions, as MDEV-12336 has
discovered, we don't need to create a separate Item_direct_ref or
Item_aggregate_ref as they will be computed directly from the top-level
item once the window function argument columns are computed.
OK to push but add comment before IF with return explaining it.
---
mysql-test/r/win.result | 12
mysql-test/t/win.test | 10 ++
sql/item.cc | 6 +++---
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/mysql-test/r/win.result b/mysql-test/r/win.result
index ec83998aa98..a67c336e5b4 100644
--- a/mysql-test/r/win.result
+++ b/mysql-test/r/win.result
@@ -3085,3 +3085,15 @@ select max(id), rank() over (order by max(id)) from t1
where id < 3;
max(id) rank() over (order by max(id))
2 1
drop table t1;
+#
+# main.win failure post MDEV-12336
+#
+create table t(a decimal(35,10), b int);
+insert into t values (1, 10), (2, 20), (3, 30);
+prepare stmt from "SELECT (CASE WHEN sum(t.a) over (partition by t.b)=1 THEN 1000
ELSE 300 END) AS a FROM t";
+execute stmt;
+a
+1000
+300
+300
+drop table t;
diff --git a/mysql-test/t/win.test b/mysql-test/t/win.test
index 95d32c5bd14..0ecb2b35074 100644
--- a/mysql-test/t/win.test
+++ b/mysql-test/t/win.test
@@ -1877,3 +1877,13 @@ select count(max(id)) over (order by max(id)) from t1 where
id < 3;
select max(id), rank() over (order by max(id)) from t1 where id < 3;
drop table t1;
+
+--echo #
+--echo # main.win failure post MDEV-12336
+--echo #
+create table t(a decimal(35,10), b int);
+insert into t values (1, 10), (2, 20), (3, 30);
+
+prepare stmt from "SELECT (CASE WHEN sum(t.a) over (partition by t.b)=1 THEN 1000
ELSE 300 END) AS a FROM t";
+execute stmt;
+drop table t;
diff --git a/sql/item.cc b/sql/item.cc
index df615b5ace9..05e5fd1ce45 100644
--- a/sql/item.cc
+++ b/sql/item.cc
@@ -1920,6 +1920,9 @@ void Item::split_sum_func2(THD *thd, Ref_ptr_array
ref_pointer_array,
point to the temporary table.
*/
split_sum_func(thd, ref_pointer_array, fields, split_flags);
+if (type() == FUNC_ITEM) {
+ return;
+}
}
else
{
@@ -1979,9 +1982,6 @@ void Item::split_sum_func2(THD *thd, Ref_ptr_array
ref_pointer_array,
&ref_pointer_array[el], 0, name
return; // fatal_error is set
}
- else if (type() == FUNC_ITEM &&
- ((Item_func *) this)->with_window_func)
-return;
else
{
if (!(item_ref= (new (thd->mem_root)
___
commits mailing list
comm...@mariadb.org
https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] c5975eaea17: MDEV-7339 Server crashes in Item_func_trig_cond::val_int
Hi! Am 12.07.2017 um 10:39 schrieb s...@mariadb.org: revision-id: c5975eaea174460e774e77717e972a8d32e6c8de (mariadb-5.5.56-38-gc5975eaea17) parent(s): f305a7ce4bccbd56520d874e1d81a4f29bc17a96 author: Sergei Golubchik committer: Sergei Golubchik timestamp: 2017-07-12 10:39:02 +0200 message: MDEV-7339 Server crashes in Item_func_trig_cond::val_int Item_in_subselect::pushed_cond_guards[] array is allocated only when left_expr->maybe_null. And it is used (for row expressions) when left_expr->element_index(i)->maybe_null. For left_expr being a multi-column subquery, its maybe_null is always false when the subquery doesn't use tables (see Item_singlerow_subselect::fix_length_and_dec() and subselect_single_select_engine::fix_length_and_dec()), otherwise it's always true. But row elements can be NULL regardless, so let's always allocate pushed_cond_guards for multi-column subqueries, no matter whether its maybe_null was forced to true or false. OK to push! [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] be55bbc2b20: MDEV-7826 Server crashes in Item_subselect::enumerate_field_refs_processor
Hi, Sergei! Am 12.07.2017 um 12:49 schrieb s...@mariadb.org: revision-id: be55bbc2b206f2fe295ad4179b23791c3119fe02 (mariadb-5.5.56-39-gbe55bbc2b20) parent(s): c5975eaea174460e774e77717e972a8d32e6c8de author: Sergei Golubchik committer: Sergei Golubchik timestamp: 2017-07-12 12:49:29 +0200 message: MDEV-7826 Server crashes in Item_subselect::enumerate_field_refs_processor upper->item can be NULL if we're referring to an aggregate function OK to push! [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 05b678bc8c1: MDEV-12489 The select stmt may fail due to "having clause is ambiguous" unexpected
Hi, Sergei! Am 12.07.2017 um 18:13 schrieb s...@mariadb.org: revision-id: 05b678bc8c166c9015ca3dc3ccd9e9c89094f3ca (mariadb-5.5.56-42-g05b678bc8c1) parent(s): c83d6ff881dcfd1cc68124a9663c2a31ca7e2dce author: Sergei Golubchik committer: Sergei Golubchik timestamp: 2017-07-12 17:46:19 +0200 message: MDEV-12489 The select stmt may fail due to "having clause is ambiguous" unexpected only compare field references with an alias (from the SELECT clause) when this reference doesn't specify an explicit table name part. OK to push! [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 1 Transaction and several threads
Hi! Am 03.08.2017 um 13:39 schrieb Sergei Golubchik: Hi, Sanja! FYI: https://jira.mariadb.org/browse/MDEV-515 and https://jira.mariadb.org/browse/MDEV-5835 It is https://jira.mariadb.org/browse/MDEV-13048 On Aug 03, Jan Lindström wrote: Hi, If we talk about bulk load I would write directly .ibd file format pages, now as InnoDB has always some order between pages doing this in parallel has challenges, we can read and parse input, sort it, reformat to InnoDB pages, write these pages (maybe you could do this also parallel). To speed this up, I would remove secondary keys that are not needed from table and rebuild them after bulk load. R: Jan On Thu, Aug 3, 2017 at 12:09 PM, Oleksandr Byelkin wrote: I am thinking about efficient inserting in a table using several threads (LOAD), is it possible (and how difficult if it does) to make inserts with help of several threads abut inside one InnoDB transaction (maybe one XA transaction)? Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 730a22c: Fixed bug mdev-13453 Executing a query via CTE requires more permissions
Am 14.11.2017 um 01:06 schrieb IgorBabaev:
revision-id: 730a22c1ce1010e853e7a3e807d1d07409ec4dfc
(mariadb-10.2.10-28-g730a22c)
parent(s): 1e2d4f677e08294691a7d218acb3b9f78727ae18
author: Igor Babaev
committer: Igor Babaev
timestamp: 2017-11-13 16:06:04 -0800
message:
Fixed bug mdev-13453 Executing a query via CTE requires more permissions
than the query itself
ACL checks were not properly supported for tables used in CTE
specifications. This patch fixes the problem.
---
mysql-test/r/cte_nonrecursive.result | 58
mysql-test/t/cte_nonrecursive.test | 51 +++
sql/sql_acl.cc | 4 +++
sql/sql_cte.cc | 3 +-
sql/sql_parse.cc | 4 +++
5 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/mysql-test/r/cte_nonrecursive.result
b/mysql-test/r/cte_nonrecursive.result
index ebe1aae..92f9151 100644
--- a/mysql-test/r/cte_nonrecursive.result
+++ b/mysql-test/r/cte_nonrecursive.result
@@ -1147,3 +1147,61 @@ SELECT * FROM cte_test;
a
1
DROP VIEW cte_test;
+#
+# MDEV-13453:
+#
[skip]
--- a/mysql-test/t/cte_nonrecursive.test
+++ b/mysql-test/t/cte_nonrecursive.test
@@ -790,3 +790,54 @@ SHOW CREATE VIEW cte_test;
SELECT * FROM cte_test;
DROP VIEW cte_test;
+
+--echo #
+--echo # MDEV-13453: privileges checking for CTE
+--echo #
+
This is for sure do not match results above, so please fix it and make
sure that full test suite passed.
[skip]
--- a/sql/sql_acl.cc
+++ b/sql/sql_acl.cc
@@ -7557,6 +7557,10 @@ bool check_grant(THD *thd, ulong want_access, TABLE_LIST
*tables,
tl->correspondent_table ? tl->correspondent_table : tl;
sctx= t_ref->security_ctx ? t_ref->security_ctx : thd->security_ctx;
+if (tl->with ||
+(tl->with= tl->select_lex->find_table_def_in_with_clauses(tl)))
+ continue;
+
const ACL_internal_table_access *access=
get_cached_table_access(&t_ref->grant.m_internal,
t_ref->get_db_name(),
diff --git a/sql/sql_cte.cc b/sql/sql_cte.cc
index 6fe08e3..e1bd455 100644
--- a/sql/sql_cte.cc
+++ b/sql/sql_cte.cc
@@ -823,9 +823,10 @@ st_select_lex_unit *With_element::clone_parsed_spec(THD
*thd,
tbl;
tbl= tbl->next_global)
{
-tbl->grant.privilege= with_table->grant.privilege;
spec_tables_tail= tbl;
}
+ if (check_table_access(thd, SELECT_ACL, spec_tables, FALSE, UINT_MAX, FALSE))
+goto err;
if (spec_tables)
{
if (with_table->next_global)
diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc
index bf5144b..39a4da9 100644
--- a/sql/sql_parse.cc
+++ b/sql/sql_parse.cc
@@ -3443,6 +3443,10 @@ mysql_execute_command(THD *thd)
ulong privileges_requested= lex->exchange ? SELECT_ACL | FILE_ACL :
SELECT_ACL;
+res= check_dependencies_in_with_clauses(thd->lex->with_clauses_list);
+if (res)
+ break;
Above works only for SELECT, do we support CTE in subselects which can
be put everywhere?
+
if (all_tables)
res= check_table_access(thd,
privileges_requested,
___
commits mailing list
comm...@mariadb.org
https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] de21526: This is a full cost-based implementation of the optimization that employs
Hi, Igor! Am 29.12.2017 um 01:47 schrieb IgorBabaev: revision-id: de215264682a9f3291ca028fb3ae052ecb191ca3 (mariadb-10.3.3-4-gde21526) parent(s): 7a66e0ab8f52f3bd32850463daa05f9a2401e6b1 author: Igor Babaev committer: Igor Babaev timestamp: 2017-12-28 16:47:25 -0800 message: This is a full cost-based implementation of the optimization that employs splitting technique for equi-joins of materialized derived tables/views/CTEs. (see mdev-13369 and mdev-13389). I have to make special mention of really good description. As we agreed OK to push after adding test of double execution. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 81965f0: Fixed mdev-14852 Fails to reopen temp table within standard CTE
Am 05.01.2018 um 08:40 schrieb IgorBabaev:
revision-id: 81965f03065b84322f2d03d784893179e8b79fd9
(mariadb-10.2.12-6-g81965f0)
parent(s): 0f253d3e644d3027face26371eb1bb59e8280728
author: Igor Babaev
committer: Igor Babaev
timestamp: 2018-01-04 23:40:37 -0800
message:
Fixed mdev-14852 Fails to reopen temp table within standard CTE
If the specification of a CTE contains a reference to a temporary table
then THD::open_temporary_table() must be called for this reference for
any occurrence of the CTE in the query. By mistake this was done only
for the first occurrences of CTEs.
The patch fixes this problem in With_element::clone_parsed_spec().
It also moves there the call of check_dependencies_in_with_clauses()
to its proper place before the call of check_table_access().
Additionally the patch optimizes the number of calls of the
function check_dependencies_in_with_clauses().
OK to push!
---
mysql-test/r/cte_nonrecursive.result | 30 ++
mysql-test/t/cte_nonrecursive.test | 29 +
sql/sql_cte.cc | 7 +++
sql/sql_parse.cc | 22 +-
sql/sql_prepare.cc | 11 +++
5 files changed, 74 insertions(+), 25 deletions(-)
diff --git a/mysql-test/r/cte_nonrecursive.result
b/mysql-test/r/cte_nonrecursive.result
index b1b41b1..c1f4c9f 100644
--- a/mysql-test/r/cte_nonrecursive.result
+++ b/mysql-test/r/cte_nonrecursive.result
@@ -1265,3 +1265,33 @@ a
4
deallocate prepare stmt;
drop table t1;
+#
+# MDEV-14852: CTE using temporary table in query
+# with two references to the CTE
+#
+create temporary table t1 (i int);
+insert into t1 values (5),(4),(1),(2),(3);
+with
+c1 as (select i from t1),
+c2 as (select i from c1 where c1.i=2)
+select i from c1 where i > 3 union select i from c2;
+i
+5
+4
+2
+drop table t1;
+create table t1 (term char(10));
+create temporary table t2 (term char(10));
+insert into t1 values ('TERM01'),('TERM02'),('TERM03');
+insert into t2 values ('TERM02'),('TERM03'),('TERM04');
+with c1 as (select * from t1), c2 as (select * from t2)
+(select * from c1 left outer join c2 on c1.term = c2.term)
+union all
+(select * from c1 right outer join c2 on c1.term = c2.term
+where c1.term is null);
+term term
+TERM02 TERM02
+TERM03 TERM03
+TERM01 NULL
+NULL TERM04
+drop table t1,t2;
diff --git a/mysql-test/t/cte_nonrecursive.test
b/mysql-test/t/cte_nonrecursive.test
index 1f21dbc..9436665 100644
--- a/mysql-test/t/cte_nonrecursive.test
+++ b/mysql-test/t/cte_nonrecursive.test
@@ -853,3 +853,32 @@ execute stmt;
deallocate prepare stmt;
drop table t1;
+
+--echo #
+--echo # MDEV-14852: CTE using temporary table in query
+--echo # with two references to the CTE
+--echo #
+
+create temporary table t1 (i int);
+insert into t1 values (5),(4),(1),(2),(3);
+
+with
+c1 as (select i from t1),
+c2 as (select i from c1 where c1.i=2)
+select i from c1 where i > 3 union select i from c2;
+
+drop table t1;
+
+create table t1 (term char(10));
+create temporary table t2 (term char(10));
+
+insert into t1 values ('TERM01'),('TERM02'),('TERM03');
+insert into t2 values ('TERM02'),('TERM03'),('TERM04');
+
+with c1 as (select * from t1), c2 as (select * from t2)
+(select * from c1 left outer join c2 on c1.term = c2.term)
+union all
+(select * from c1 right outer join c2 on c1.term = c2.term
+ where c1.term is null);
+
+drop table t1,t2;
diff --git a/sql/sql_cte.cc b/sql/sql_cte.cc
index 601c192..d12948f 100644
--- a/sql/sql_cte.cc
+++ b/sql/sql_cte.cc
@@ -817,12 +817,19 @@ st_select_lex_unit *With_element::clone_parsed_spec(THD
*thd,
parse_status= parse_sql(thd, &parser_state, 0);
if (parse_status)
goto err;
+
+ if (check_dependencies_in_with_clauses(lex->with_clauses_list))
+goto err;
+
spec_tables= lex->query_tables;
spec_tables_tail= 0;
for (TABLE_LIST *tbl= spec_tables;
tbl;
tbl= tbl->next_global)
{
+if (!tbl->derived && !tbl->schema_table &&
+thd->open_temporary_table(tbl))
+ goto err;
spec_tables_tail= tbl;
}
if (check_table_access(thd, SELECT_ACL, spec_tables, FALSE, UINT_MAX,
FALSE))
diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc
index f00c74b..6d068eb 100644
--- a/sql/sql_parse.cc
+++ b/sql/sql_parse.cc
@@ -2990,6 +2990,9 @@ mysql_execute_command(THD *thd)
thd->get_stmt_da()->opt_clear_warning_info(thd->query_id);
}
+ if (check_dependencies_in_with_clauses(thd->lex->with_clauses_list))
+DBUG_RETURN(1);
+
#ifdef HAVE_REPLICATION
if (unlikely(thd->slave_thread))
{
@@ -3446,14 +3449,6 @@ mysql_execute_command(THD *thd)
ulong privileges_requested= lex->exchange ? SELECT_ACL | FILE_ACL :
SELECT_ACL;
-/*
- The same function must be called for DML commands
- when CTEs are supported in DML statements
-*/
-res= check_dependencies_in_with_clauses(thd->lex->with_clauses_list);
-
Re: [Maria-developers] [Commits] fbe0fc2: Fixed mdev-14879 Lost rows for query using recursive CTE
Hi, Igor! Am 06.01.2018 um 18:32 schrieb IgorBabaev: revision-id: fbe0fc2d87cb1bdb9f7040d44ad3c58a94857e20 (mariadb-10.2.12-14-gfbe0fc2) parent(s): 15b1840f43be8c660382458826e9d5a47d148a67 author: Igor Babaev committer: Igor Babaev timestamp: 2018-01-06 09:32:47 -0800 message: Fixed mdev-14879 Lost rows for query using recursive CTE with recursive reference in subquery If a recursive CTE uses a subquery with recursive reference then the virtual function reset() must be called after each iteration performed at the execution of the CTE. OK to push. [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] [Commits] 4b4267288cb: MDEV-14743: Server crashes in Item_func_match::init_search
Hi, Sergei!
Am 12.01.2018 um 17:37 schrieb Sergei Golubchik:
Hi, Oleksandr!
Two thoughts.
1. Please use
if (!ifm->fixed)
then you'll only need one #ifdef.
OK, then I'll use __unlikely() also.
2. How does it work with the iterator? if you remove the current element
from the list and then iterator with jump to the next one, won't it
cause one element to be skipped?
I do not know why, there was used normal iterator which allow removal,
actually it should be List_iterator_fast.
But as far as it is normal removing should work (it just step back
current position, so next will be correct)
On Jan 10, Oleksandr Byelkin wrote:
revision-id: 4b4267288cb2668717cc70537eb7e79cecaff58a
(mariadb-5.5.58-24-g4b4267288cb)
parent(s): a408e881cf73d06fc92097fce6ef9584e16edf77
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2018-01-10 12:22:56 +0100
message:
MDEV-14743: Server crashes in Item_func_match::init_search
Remove non prepared (and so belonging to removed clauses FT functions) from the
list.
in later version it will be fixed by building the list during preparation.
diff --git a/sql/sql_base.cc b/sql/sql_base.cc
index c06c4fcff29..26e302ded35 100644
--- a/sql/sql_base.cc
+++ b/sql/sql_base.cc
@@ -9550,7 +9550,19 @@ int init_ftfuncs(THD *thd, SELECT_LEX *select_lex, bool
no_order)
DBUG_PRINT("info",("Performing FULLTEXT search"));
while ((ifm=li++))
- ifm->init_search(no_order);
+#if MYSQL_VERSION_ID < 100213
+ if (ifm->fixed)
+#endif
+ifm->init_search(no_order);
+#if MYSQL_VERSION_ID < 100213
+ else
+/*
+ it mean that clause where was FT function was removed, so we have
+ to remove the function from the list.
+*/
+li.remove();
+#endif
+
}
return 0;
}
Regards,
Sergei
Chief Architect MariaDB
and secur...@mariadb.org
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Fwd: [Commits] b32031991e4: initial oracle parser fix
Am 10.04.2018 um 10:58 schrieb Alexander Barkov:
Hello Sanja,
I reviewed your recent changes in "10.3-MDEV-11953"
(and the attached additional patch for sql_yacc_ora.yy)
I have some proposals:
1. Can you please move huge pieces of the code from sql_yacc.yy to LEX
or other relevant classes?
It makes the grammar much more readable (patches are aslo much more
readable).
I'd move the relevant pieces of the code to LEX as a separate patch,
even before fixing the grammar.
OK
2. You're adding too many main_select_push() and pop_select().
Please move them to upper level rules (it should be possible in many cases).
Impossible
Add new helper rules when needed.
For example, this piece of code repeats many times:
+ {
+if (Lex->main_select_push())
+ MYSQL_YYABORT;
+ }
+ expr
+ {
+Lex->pop_select(); //main select
+$$= $3;
It deserved a rule, say, expr_with_select_push_pop.
You can find a better name :)
OK
- Serg and I spent a lot of time working on this task:
MDEV-8909 union parser cleanup
(and its 13 dependency tasks, and 3 related tasks,
see the "Issue links" section in MDEV).
We think that it should be the parser who disallows bad grammar, instead
of post-analysis with raising errors like
ER_CANT_USE_OPTION_HERE.
Please keep using the same approach.
The task did not made parser recognizing brackets, and I have no ideas
how to return parser errors when all SELECT parsed in the same way in
difference from the previous parser which could recognize only one level
of SELECTs.
Thanks!
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Fwd: [Commits] b32031991e4: initial oracle parser fix
Hi, Alexander! Am 10.04.2018 um 15:00 schrieb Alexander Barkov: Hello Sanja, [skip] Can you give an example of a query that is not parsed by the current 10.3 parser, but is parsed in 10.3-MDEV-11953 ? There is mysql-test/main/brackets.test ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 346c8ab9533: MDEV-11975: SQLCOM_PREPARE of EXPLAIN & ANALYZE statement do not return correct metadata info
Am 19.04.2018 um 11:31 schrieb Sergei Golubchik: Hi, Oleksandr! On Apr 18, Oleksandr Byelkin wrote: revision-id: 346c8ab9533a3de6a4cb348428402ffee2aa8da2 (mariadb-10.3.6-16-g346c8ab9533) parent(s): cff60be7fe159fdcb2517ce8441610ad512aa7d0 author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2018-04-18 19:34:12 +0200 message: MDEV-11975: SQLCOM_PREPARE of EXPLAIN & ANALYZE statement do not return correct metadata info Added metadate info after prepare EXPLAIN/ANALYZE. --- mysql-test/main/mysql_client_test.result | 122 mysql-test/main/mysql_client_test.test | 7 +- sql/sql_class.cc | 18 +- sql/sql_class.h | 3 +- sql/sql_explain.cc | 3 +- sql/sql_parse.cc | 5 +- sql/sql_prepare.cc | 24 ++- sql/sql_prepare.h| 2 + tests/mysql_client_test.c| 323 ++- 9 files changed, 493 insertions(+), 14 deletions(-) diff --git a/mysql-test/main/mysql_client_test.result b/mysql-test/main/mysql_client_test.result index 83ef8d442b3..20385acfa00 100644 --- a/mysql-test/main/mysql_client_test.result +++ b/mysql-test/main/mysql_client_test.result @@ -122,5 +122,127 @@ EOF mysql_stmt_next_result(): 0; field_count: 0 # +# cat MYSQL_TMP_DIR/test_explain_meta.out.log +# okay, altought I'd rather add prepare metadata output to mysqltest. Like, either print prepare metadata on --enable_metadata or introduce a new command --enable_prepare_metadata This two functionality are independent. We have speciall "IFs" in the code to return SQL level prepare in some other place and actually nobody really care what SQL level prepare return (of course I can fix it also, but main request came from JDBC). +SELECT number of fields: 1 +EXPALIN number of fields: 10 + - 0: name: 'id'/''; table: ''/''; db: ''; catalog: 'def'; length: 3; max_length: 0; type: 8; decimals: 0 + - 1: name: 'select_type'/''; table: ''/''; db: ''; catalog: 'def'; length: 57; max_length: 0; type: 253; decimals: 39 + - 2: name: 'table'/''; table: ''/''; db: ''; catalog: 'def'; length: 192; max_length: 0; type: 253; decimals: 39 + - 3: name: 'type'/''; table: ''/''; db: ''; catalog: 'def'; length: 30; max_length: 0; type: 253; decimals: 39 + - 4: name: 'possible_keys'/''; table: ''/''; db: ''; catalog: 'def'; length: 12288; max_length: 0; type: 253; decimals: 39 + - 5: name: 'key'/''; table: ''/''; db: ''; catalog: 'def'; length: 192; max_length: 0; type: 253; decimals: 39 + - 6: name: 'key_len'/''; table: ''/''; db: ''; catalog: 'def'; length: 12288; max_length: 0; type: 253; decimals: 39 + - 7: name: 'ref'/''; table: ''/''; db: ''; catalog: 'def'; length: 6144; max_length: 0; type: 253; decimals: 39 + - 8: name: 'rows'/''; table: ''/''; db: ''; catalog: 'def'; length: 10; max_length: 0; type: 8; decimals: 0 + - 9: name: 'Extra'/''; table: ''/''; db: ''; catalog: 'def'; length: 765; max_length: 0; type: 253; decimals: 39 +EXPALIN JSON number of fields: 1 + - 0: name: 'EXPLAIN'/''; table: ''/''; db: ''; catalog: 'def'; length: 234; max_length: 0; type: 253; decimals: 39 +ANALYZE number of fields: 13 + - 0: name: 'id'/''; table: ''/''; db: ''; catalog: 'def'; length: 3; max_length: 0; type: 8; decimals: 0 + - 1: name: 'select_type'/''; table: ''/''; db: ''; catalog: 'def'; length: 57; max_length: 0; type: 253; decimals: 39 + - 2: name: 'table'/''; table: ''/''; db: ''; catalog: 'def'; length: 192; max_length: 0; type: 253; decimals: 39 + - 3: name: 'type'/''; table: ''/''; db: ''; catalog: 'def'; length: 30; max_length: 0; type: 253; decimals: 39 + - 4: name: 'possible_keys'/''; table: ''/''; db: ''; catalog: 'def'; length: 12288; max_length: 0; type: 253; decimals: 39 + - 5: name: 'key'/''; table: ''/''; db: '&
Re: [Maria-developers] 346c8ab9533: MDEV-11975: SQLCOM_PREPARE of EXPLAIN & ANALYZE statement do not return correct metadata info
Hi, Sergei!
Am 20.04.2018 um 09:29 schrieb Sergei Golubchik:
Hi, Oleksandr!
On Apr 20, Oleksandr Byelkin wrote:
Am 19.04.2018 um 11:31 schrieb Sergei Golubchik:
+# cat MYSQL_TMP_DIR/test_explain_meta.out.log
+#
okay, altought I'd rather add prepare metadata output to mysqltest.
Like, either print prepare metadata on --enable_metadata or introduce a new
command --enable_prepare_metadata
This two functionality are independent. We have speciall "IFs" in the
code to return SQL level prepare in some other place and actually nobody
really care what SQL level prepare return (of course I can fix it also,
but main request came from JDBC).
No-no. I don't mean sql prepare. I mean this part of mysqltest.cc:
==
if (do_stmt_prepare(cn, query, query_len))
{
handle_error(command, mysql_stmt_errno(stmt),
mysql_stmt_error(stmt), mysql_stmt_sqlstate(stmt), ds);
goto end;
}
+ if (display_metadata)
+ append_metadata(ds, fields, num_fields);
==
then one will be able to run the test, say
--enable_metadata
EXPLAIN SELECT * FROM mysql.user;
--disable_metadata
and in --ps-protocol it'll show you metadata from prepared EXPLAIN.
May be --enable_metadata cannot be used for that and it'll need a new
command --enable_prepare_metadata (like we have --enable_prepare_warnings)
It is a big surprise for me but our --ps-protocol appeared to test only
SELECT (by regular expression chosen) and I think fixing it is quite
separate task.
(IMHO IT should be fixed, but the task is irrelivant)
[skip]
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 980a5c31880: MDEV-14572: Assertion `! is_set()' failed in Diagnostics_area::set_eof_status upon EXPLAIN UPDATE in PS
Am 29.01.2018 um 01:02 schrieb Sergei Golubchik: Hi, Oleksandr! On Jan 28, Oleksandr Byelkin wrote: Hi, Sergei! Flag in SELECT_LEX options dropped at the end of execution (in our case prepare). All commands where EXPLAIN is possible restore the flag in main SELECT_LEX (in mysql_explain_union()) except UPDATE (because it do not use mysql_explain_union() for explain). Without the flag it first try to send OK (as part of update) then EOF as part of EXPLAIN. Ok. 1. Why does it not use mysql_explain_union() ? It is question to them who made explain for non SELECT statements (probably Sergey Petrunia) as I can see it just have a bit different call pathes. 2. Why EXPLAIN flag is need to be removed and restored anyway? Because it is how our EXPLAIN works (written without taking into account re-execution). If remove the flag cleanup it will change output of prepared explain EXPLAIN. 3. Please append the following to the commit comment: " Without it, mysql_update() didn't know that there will be EXPLAIN result set and was sending OK at the end of the update, which conflicted with the EOF sent later by EXPLAIN. OK " On Sun, Jan 28, 2018 at 2:45 PM, Sergei Golubchik wrote: Hi, Oleksandr! On Dec 22, Oleksandr Byelkin wrote: revision-id: 980a5c318803d6aa7355e019869597976dcf19bf (mariadb-10.0.33-37-g980a5c31880) parent(s): 042f763268c0f209e7c12e0a6a72bb5d204dfe29 author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2017-12-22 14:00:10 +0100 message: MDEV-14572: Assertion `! is_set()' failed in Diagnostics_area::set_eof_status upon EXPLAIN UPDATE in PS Restore EXPAIN flag in SELECT_LEX before execution multi-update by flag in LEX (the same but in other way made before INSERT/DELETE/SELECT) Please explain what was the reason for the bug, why the status was set twice, and how your change fixes it. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 46e0c8a9219: MDEV-11071: Assertion `thd->transaction.stmt.is_empty()' failed in Locked_tables_list::unlock_locked_table
Am 13.06.2018 um 12:08 schrieb Sergei Golubchik:
Hi, Oleksandr!
Looks good, but please see a few comments below.
On May 08, Oleksandr Byelkin wrote:
revision-id: 46e0c8a921978e7b95adf3f17f3c85b18d9f9ef6
(mariadb-10.2.14-78-g46e0c8a9219)
parent(s): 9bcd0f5fea8ca26742b10d37b95a966c69909ff1
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2018-05-08 15:26:26 +0200
message:
MDEV-11071: Assertion `thd->transaction.stmt.is_empty()' failed in
Locked_tables_list::unlock_locked_table
fix_length_and_dec now return result (error/OK)
diff --git a/sql/item.h b/sql/item.h
index 8921ee76f6a..e9713730a1c 100644
--- a/sql/item.h
+++ b/sql/item.h
@@ -4210,7 +4210,7 @@ class Item_func_or_sum: public Item_result_field,
also to make printing of items inherited from Item_sum uniform.
*/
virtual const char *func_name() const= 0;
- virtual void fix_length_and_dec()= 0;
+ virtual bool fix_length_and_dec()= 0;
1. I wonder, if you change fix_length_and_dec to void in one of the derived
classes, will you get a compiler warning for that?
it will lead to an error (overriding virtual function).
2. may be also __attribute__ ((warn_unused_result)) here?
I don't know how it'll work on virtual methods, may be it won't.
both questions are for the use case "what if we merge some fix_length_and_dec
related changes from 10.1, will the compiler tell us to update them?"
Somehow warning is not issued if add the attribute here (it have to be
added to each definition to work as I understand).
bool const_item() const { return const_item_cache; }
table_map used_tables() const { return used_tables_cache; }
Item* build_clone(THD *thd, MEM_ROOT *mem_root);
diff --git a/sql/item_cmpfunc.cc b/sql/item_cmpfunc.cc
index 44cc4f3cae9..46cf412e229 100644
--- a/sql/item_cmpfunc.cc
+++ b/sql/item_cmpfunc.cc
@@ -535,8 +535,9 @@ void Item_bool_rowready_func2::fix_length_and_dec()
we have to check for out of memory conditions here
*/
if (!args[0] || !args[1])
-return;
- setup_args_and_comparator(current_thd, &cmp);
+return FALSE;
+ bool res= setup_args_and_comparator(current_thd, &cmp);
+ return res;
not that it matters much (no need to change), but why didn't you
return setup_args_and_comparator(current_thd, &cmp);
directly?
just missed it, it is not problem to fix
}
diff --git a/sql/item_cmpfunc.h b/sql/item_cmpfunc.h
index de1b27cff1a..5efb98bc81d 100644
--- a/sql/item_cmpfunc.h
+++ b/sql/item_cmpfunc.h
@@ -911,10 +911,12 @@ class Item_func_strcmp :public Item_int_func
longlong val_int();
uint decimal_precision() const { return 1; }
const char *func_name() const { return "strcmp"; }
- void fix_length_and_dec()
+ bool fix_length_and_dec()
{
-agg_arg_charsets_for_comparison(cmp_collation, args, 2);
+if (agg_arg_charsets_for_comparison(cmp_collation, args, 2))
+ return TRUE;
fix_char_length(2); // returns "1" or "0" or "-1"
this comment is kinda weird. remove?
OK
+return FALSE;
}
Item *get_copy(THD *thd, MEM_ROOT *mem_root)
{ return get_item_copy(thd, mem_root, this); }
@@ -1987,10 +1997,10 @@ class Item_func_like :public Item_bool_func2
const char *func_name() const { return "like"; }
enum precedence precedence() const { return CMP_PRECEDENCE; }
bool fix_fields(THD *thd, Item **ref);
- void fix_length_and_dec()
+ bool fix_length_and_dec()
{
max_length= 1;
-agg_arg_charsets_for_comparison(cmp_collation, args, 2);
should this one also be __attribute__ ((warn_unused_result)) ?
+return agg_arg_charsets_for_comparison(cmp_collation, args, 2);
}
void cleanup();
diff --git a/sql/item_subselect.cc b/sql/item_subselect.cc
index 4214980c36c..ca49e06a9e7 100644
--- a/sql/item_subselect.cc
+++ b/sql/item_subselect.cc
@@ -904,9 +905,10 @@ Item::Type Item_subselect::type() const
}
-void Item_subselect::fix_length_and_dec()
+bool Item_subselect::fix_length_and_dec()
{
engine->fix_length_and_dec(0);
what about subselect_engine::fix_length_and_dec() ?
should return bool too, I guess, right?
yes, will be fixed
+ return FALSE;
}
diff --git a/sql/sql_table.cc b/sql/sql_table.cc
index 9e7973b745c..f3cb85f01d3 100644
--- a/sql/sql_table.cc
+++ b/sql/sql_table.cc
@@ -4894,7 +4894,13 @@ int create_table_impl(THD *thd,
file= mysql_create_frm_image(thd, orig_db, orig_table_name, create_info,
alter_info, create_table_mode, key_info,
key_count, frm);
-if (!file)
+/*
+ We have to check thd->is_error() here because it can be set by
+ Item::val* for example, and before it will be cought accidentally by
+ Item_func::fix_fields() of the next call. Now we removed the check
+ from Item_func::fix_fields()
+*/
this is a very confusing comment,
don't
Re: [Maria-developers] 46e0c8a9219: MDEV-11071: Assertion `thd->transaction.stmt.is_empty()' failed in Locked_tables_list::unlock_locked_table
Am 14.06.2018 um 11:44 schrieb Sergei Golubchik: Hi, Oleksandr! On Jun 14, Oleksandr Byelkin wrote: Am 13.06.2018 um 12:08 schrieb Sergei Golubchik: diff --git a/sql/sql_table.cc b/sql/sql_table.cc index 9e7973b745c..f3cb85f01d3 100644 --- a/sql/sql_table.cc +++ b/sql/sql_table.cc @@ -4894,7 +4894,13 @@ int create_table_impl(THD *thd, file= mysql_create_frm_image(thd, orig_db, orig_table_name, create_info, alter_info, create_table_mode, key_info, key_count, frm); -if (!file) +/* + We have to check thd->is_error() here because it can be set by + Item::val* for example, and before it will be cought accidentally by + Item_func::fix_fields() of the next call. Now we removed the check + from Item_func::fix_fields() +*/ and I still don't understand why do you need to check for thd->is_error() here because it catch some other errors which never will be checked and fixing this IMHO is other matter and in higher version. Some other errors like what? like an error in val_* call due to some incompatibility of arguments during mysql_create_frm_image() as I remember. i.e. our tests will fail without this check because the error left unchecked till it is too late. I put TODO remove this tests, but without them it will not just work. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 46e0c8a9219: MDEV-11071: Assertion `thd->transaction.stmt.is_empty()' failed in Locked_tables_list::unlock_locked_table
Am 14.06.2018 um 14:19 schrieb Sergei Golubchik: Hi, Oleksandr! On Jun 14, Oleksandr Byelkin wrote: Am 14.06.2018 um 11:44 schrieb Sergei Golubchik: On Jun 14, Oleksandr Byelkin wrote: Am 13.06.2018 um 12:08 schrieb Sergei Golubchik: diff --git a/sql/sql_table.cc b/sql/sql_table.cc index 9e7973b745c..f3cb85f01d3 100644 --- a/sql/sql_table.cc +++ b/sql/sql_table.cc @@ -4894,7 +4894,13 @@ int create_table_impl(THD *thd, file= mysql_create_frm_image(thd, orig_db, orig_table_name, create_info, alter_info, create_table_mode, key_info, key_count, frm); -if (!file) +/* + We have to check thd->is_error() here because it can be set by + Item::val* for example, and before it will be cought accidentally by + Item_func::fix_fields() of the next call. Now we removed the check + from Item_func::fix_fields() +*/ and I still don't understand why do you need to check for thd->is_error() here because it catch some other errors which never will be checked and fixing this IMHO is other matter and in higher version. Some other errors like what? like an error in val_* call due to some incompatibility of arguments during mysql_create_frm_image() as I remember. i.e. our tests will fail without this check because the error left unchecked till it is too late. I put TODO remove this tests, but without them it will not just work. Is there a test that fails without them? yes, completely unrelated tests, before the error will be caught in fix_fields() which was produced for unrelated parts of the query (and only if we have Item_func there). We just have no other mechanisms to catch error during val_* than check thd->is_error(). Wouldn't the original bug show up again? You're testing for thd->is_error() and it might be unrelated coming from some earlier error, right? I think no, because it is on the upper level. I.e. we tried to generate .frm and checking if it succeed before starting preparing other parts of the query, and actually try to execute full query if .frm was not created will lead eventually to crashes and other problems. in other words we stop execution when it is not too late because 1) it has no sens 2) it is impossible without success of the first part. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 980a5c31880: MDEV-14572: Assertion `! is_set()' failed in Diagnostics_area::set_eof_status upon EXPLAIN UPDATE in PS
Hi, Sergei! Am 18.06.2018 um 14:14 schrieb Sergei Golubchik: Hi, Oleksandr! On Jun 11, Oleksandr Byelkin wrote: Am 29.01.2018 um 01:02 schrieb Sergei Golubchik: On Jan 28, Oleksandr Byelkin wrote: Hi, Sergei! Flag in SELECT_LEX options dropped at the end of execution (in our case prepare). All commands where EXPLAIN is possible restore the flag in main SELECT_LEX (in mysql_explain_union()) except UPDATE (because it do not use mysql_explain_union() for explain). Without the flag it first try to send OK (as part of update) then EOF as part of EXPLAIN. Ok. 1. Why does it not use mysql_explain_union() ? It is question to them who made explain for non SELECT statements (probably Sergey Petrunia) as I can see it just have a bit different call pathes. So all UPDATE/DELETE restore the flag, and only multi-update didn't? What about multi-delete? all except this. Better to add tests with PREPARE and all non-select explainable commands to test it and to make sure it won't break in the future. OK 2. Why EXPLAIN flag is need to be removed and restored anyway? Because it is how our EXPLAIN works (written without taking into account re-execution). If remove the flag cleanup it will change output of prepared explain EXPLAIN. Yes, I understand why the flag has to be restored. But why it has to be removed? it was explanation why it should be removed something do not work otherwise. I tried and explain starts changing on second call. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 6df4e4a855f: MDEV-16217: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date
Hi, Sergei!
Am 09.08.2018 um 12:34 schrieb Sergei Golubchik:
Hi, Oleksandr!
See questions below. There are few changes that I'm not quite sure
about.
On Aug 08, Oleksandr Byelkin wrote:
revision-id: 6df4e4a855fe223988c12681f8caec6c49b2f629
(mariadb-10.2.16-66-g6df4e4a855f)
parent(s): 4ddcb4eb46c62cf459936554d43351db740ba14d
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2018-08-08 12:28:15 +0200
message:
MDEV-16217: Assertion `!table || (!table->read_set ||
bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date
- clean up DEFAULT() to work only with default value and correctly print
itself.
- fix of DBUG_ASSERT about fields read/write
- fix of firld marking for write based really on the thd->mark_used_columns flag
---
mysql-test/r/func_default.result | 2 +-
mysql-test/r/func_time.result| 28
mysql-test/t/func_time.test | 21 +
sql/field.cc | 21 +++--
sql/field.h | 1 +
sql/item.cc | 25 -
sql/item.h | 5 +
sql/sql_base.cc | 2 +-
8 files changed, 100 insertions(+), 5 deletions(-)
diff --git a/mysql-test/r/func_default.result b/mysql-test/r/func_default.result
index 535be10da86..1f331af287c 100644
--- a/mysql-test/r/func_default.result
+++ b/mysql-test/r/func_default.result
@@ -8,7 +8,7 @@ explain extended select default(str), default(strnull),
default(intg), default(r
idselect_type table typepossible_keys key key_len ref
rowsfilteredExtra
1 SIMPLE t1 system NULLNULLNULLNULL1 100.00
Warnings:
-Note 1003select default('') AS `default(str)`,default('') AS
`default(strnull)`,default(0) AS `default(intg)`,default(0) AS `default(rel)`
from dual
+Note 1003select default(`str`) AS `default(str)`,default(`strnull`) AS
`default(strnull)`,default(`intg`) AS `default(intg)`,default(`rel`) AS
`default(rel)` from dual
This looks rather fishy. There can be no columns str and strnull in
dual.
it is how table elimination work, table is eliminated (table is read)
but default values is taking from it.
Also previous output was also fishy (if not more) what is default('') ?
maybe putting there full defined field (with table/database (as
discussed later) will helps to make it a bit more clear).
Please add a test case with a view, to make sure you only get this
effect (column names and dual) in explain extended (where it doesn't
matter), but not in a view (where it does).
OK
select * from t1 where str <> default(str);
str strnull intgrel
0 0
diff --git a/mysql-test/r/func_time.result b/mysql-test/r/func_time.result
index 55c2c93eb56..51f51820efc 100644
--- a/mysql-test/r/func_time.result
+++ b/mysql-test/r/func_time.result
@@ -3260,3 +3260,31 @@ DROP TABLE t1,t2;
#
# End of 10.1 tests
#
+#
+# MDEV-16217: Assertion `!table || (!table->read_set ||
+# bitmap_is_set(table->read_set, field_index))'
+# failed in Field_num::get_date
+#
+CREATE TABLE t1 (pk int default 0, a1 date);
+INSERT INTO t1 VALUES (1,'1900-01-01'),(2,NULL),(3,NULL),(4,NULL);
+CREATE VIEW v1 AS
+SELECT t1.pk AS pk, t1.a1 AS a1 FROM t1;
+SELECT a1 BETWEEN (('2018-08-24')) AND (DEFAULT(pk)) FROM v1;
+a1 BETWEEN (('2018-08-24')) AND (DEFAULT(pk))
+0
+NULL
+NULL
+NULL
+SELECT a1 BETWEEN (('2018-08-24')) AND (~ DEFAULT(pk)) FROM v1;
+a1 BETWEEN (('2018-08-24')) AND (~ DEFAULT(pk))
+0
+NULL
+NULL
+NULL
+Warnings:
+Warning1292Incorrect datetime value: '18446744073709551615'
+DROP VIEW v1;
+DROP TABLE t1;
+#
+# End of 10.2 tests
+#
diff --git a/mysql-test/t/func_time.test b/mysql-test/t/func_time.test
index 3503b6d5bc6..c8859feee93 100644
--- a/mysql-test/t/func_time.test
+++ b/mysql-test/t/func_time.test
@@ -1857,3 +1857,24 @@ DROP TABLE t1,t2;
--echo #
--echo # End of 10.1 tests
--echo #
+
+--echo #
+--echo # MDEV-16217: Assertion `!table || (!table->read_set ||
+--echo # bitmap_is_set(table->read_set, field_index))'
+--echo # failed in Field_num::get_date
+--echo #
+CREATE TABLE t1 (pk int default 0, a1 date);
+INSERT INTO t1 VALUES (1,'1900-01-01'),(2,NULL),(3,NULL),(4,NULL);
+
+CREATE VIEW v1 AS
+SELECT t1.pk AS pk, t1.a1 AS a1 FROM t1;
+
+SELECT a1 BETWEEN (('2018-08-24')) AND (DEFAULT(pk)) FROM v1;
+SELECT a1 BETWEEN (('2018-08-24')) AND (~ DEFAULT(pk)) FROM v1;
+
+DROP VIEW v1;
+DROP TABLE t1;
+
+--echo #
+--echo # End of 10.2 tests
+--echo #
diff --git a/sql/field.cc b/sql/field.cc
index 9ca9663f066..e12adbf47b3 100644
--- a/sql/field.cc
+++ b/sql/field.cc
@@ -70,8 +70,25 @@ const char field_separator=',';
#define BLOB_PACK_LENGTH_TO_MAX_LENGH
Re: [Maria-developers] [Commits] 7fc57734575: MDEV-6439: Server crashes in Explain_union::print_explain with explain in slow log, tis620 charset
Hi! See small comment inline. (fix and OK to push) Am 15.08.2018 um 13:36 schrieb Sergey Petrunia: MDEV-6439: Server crashes in Explain_union::print_explain with explain in slow log, tis620 charset Item_subselect::is_expensive() used to return FALSE (Inexpensive) whenever it saw that one of SELECTs in the Subquery's UNION is degenerate. It ignored the fact that other parts of the UNION might not be inexpensive, including the case where pther parts of the UNION have no query plan yet. For a subquery in form col >= ANY (SELECT 'foo' UNION SELECT 'bar') this would cause the query to be considered inexpensive when there is no query plan for the second part of the UNION, which in turn would cause the SELECT 'foo' to compute and free itself while still inside JOIN::optimize for that SELECT (See MDEV comment for full description). diff --git a/mysql-test/r/subselect_extra_no_semijoin.result b/mysql-test/r/subselect_extra_no_semijoin.result index 79bca38..200682b 100644 --- a/mysql-test/r/subselect_extra_no_semijoin.result +++ b/mysql-test/r/subselect_extra_no_semijoin.result @@ -482,3 +482,22 @@ DROP TABLE t1,t2; set optimizer_switch= @tmp_subselect_extra_derived; set optimizer_switch= @subselect_extra_no_sj_tmp; set @optimizer_switch_for_subselect_extra_test=null; +# +# MDEV-6439: Server crashes in Explain_union::print_explain with explain in slow log, tis620 charset +# +SET NAMES tis620; +set @tmp= @@global.slow_query_log; +SET GLOBAL slow_query_log = 1; +SET long_query_time = 0.01; +SET log_slow_verbosity = 'explain'; +CREATE TABLE t1 (a VARCHAR(3)) ENGINE=MyISAM; +SELECT * FROM t1 WHERE a >= ANY ( SELECT 'foo'); +a +SELECT * FROM t1 WHERE a >= ANY ( SELECT 'foo' UNION SELECT 'bar' ); +ERROR HY000: Illegal mix of collations (tis620_thai_ci,COERCIBLE) and (latin1_swedish_ci,IMPLICIT) for operation '<=' +create table t2 (b int); +insert into t2 values (1),(2),(3); +SELECT * FROM t1 WHERE a >= ANY ( SELECT 'foo' FROM t2); +ERROR HY000: Illegal mix of collations (tis620_thai_ci,COERCIBLE) and (latin1_swedish_ci,IMPLICIT) for operation '<=' +drop table t1,t2; +SET GLOBAL slow_query_log=@tmp; diff --git a/mysql-test/t/subselect_extra_no_semijoin.test b/mysql-test/t/subselect_extra_no_semijoin.test index 8aba3dd..41593fb 100644 --- a/mysql-test/t/subselect_extra_no_semijoin.test +++ b/mysql-test/t/subselect_extra_no_semijoin.test @@ -6,4 +6,34 @@ set @optimizer_switch_for_subselect_extra_test='semijoin=off,firstmatch=off,loo set optimizer_switch= @subselect_extra_no_sj_tmp; -set @optimizer_switch_for_subselect_extra_test=null; \ No newline at end of file +set @optimizer_switch_for_subselect_extra_test=null; + +--echo # +--echo # MDEV-6439: Server crashes in Explain_union::print_explain with explain in slow log, tis620 charset +--echo # + +## Using a separate client connection is easier than restoring state +connect(con1,localhost,root,,); + +SET NAMES tis620; +set @tmp= @@global.slow_query_log; +SET GLOBAL slow_query_log = 1; +SET long_query_time = 0.01; +SET log_slow_verbosity = 'explain'; + please remove above space at the end of line and push. +CREATE TABLE t1 (a VARCHAR(3)) ENGINE=MyISAM; +SELECT * FROM t1 WHERE a >= ANY ( SELECT 'foo'); +--error ER_CANT_AGGREGATE_2COLLATIONS +SELECT * FROM t1 WHERE a >= ANY ( SELECT 'foo' UNION SELECT 'bar' ); + +create table t2 (b int); +insert into t2 values (1),(2),(3); + +--error ER_CANT_AGGREGATE_2COLLATIONS +SELECT * FROM t1 WHERE a >= ANY ( SELECT 'foo' FROM t2); + +drop table t1,t2; +SET GLOBAL slow_query_log=@tmp; +disconnect con1; +connection default; + diff --git a/sql/item_subselect.cc b/sql/item_subselect.cc index a8dfdff..14b2ccd 100644 --- a/sql/item_subselect.cc +++ b/sql/item_subselect.cc @@ -575,7 +575,7 @@ bool Item_subselect::is_expensive() */ if (cur_join->optimized && (cur_join->zero_result_cause || !cur_join->tables_list)) - return false; + continue; /* If a subquery is not optimized we cannot estimate its cost. A subquery is ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] cc5c19ae523: MDEV-17401: LOAD DATA from very big file into MyISAM table results in EOF error and corrupt index
Am 18.10.18 um 13:27 schrieb Sergei Golubchik:
Hi, Oleksandr!
On Oct 12, Oleksandr Byelkin wrote:
revision-id: cc5c19ae5233ba90de086de76043774ae6c78cd7
(mariadb-5.5.61-30-gcc5c19ae523)
parent(s): acf8fc1ff8a7b2d49e25279670b04b8eb096ce0c
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2018-10-12 09:07:05 +0200
message:
MDEV-17401: LOAD DATA from very big file into MyISAM table results in EOF error
and corrupt index
my_read fixed as in higher versions.
my_pread made as my_read aware of partial read of huge chunks of files
MY_FULL_IO enabled for file operations
---
mysys/mf_iocache.c | 4
mysys/my_pread.c | 25 ++---
mysys/my_read.c| 52
3 files changed, 50 insertions(+), 31 deletions(-)
diff --git a/mysys/mf_iocache.c b/mysys/mf_iocache.c
index bd71e2ae527..9a051cf6a9e 100644
--- a/mysys/mf_iocache.c
+++ b/mysys/mf_iocache.c
@@ -282,6 +282,10 @@ int init_io_cache(IO_CACHE *info, File file, size_t
cachesize,
}
info->inited=info->aio_result.pending=0;
#endif
+ if (type == READ_CACHE || type == WRITE_CACHE || type == SEQ_READ_APPEND)
+info->myflags|= MY_FULL_IO;
+ else
+info->myflags&= ~MY_FULL_IO;
1. that's a bit redundant, it'd be enough to do it in init_io_cache.
but ok.
2. why you didn't remove MY_FULL_IO setting from reinit_io_cache?
it is 5.5 so there is no reinit_io_cache and there is no place where we
set MY_FULL_IO (it is not set at all, and this is why it had buggy
version for my_read).
DBUG_RETURN(0);
} /* init_io_cache */
diff --git a/mysys/my_pread.c b/mysys/my_pread.c
index 51b4c5f5599..5cbd6b4316b 100644
--- a/mysys/my_pread.c
+++ b/mysys/my_pread.c
@@ -47,8 +47,7 @@
size_t my_pread(File Filedes, uchar *Buffer, size_t Count, my_off_t offset,
myf MyFlags)
{
- size_t readbytes;
- int error= 0;
+ size_t readbytes, save_count= 0;
DBUG_ENTER("my_pread");
@@ -66,11 +65,10 @@ size_t my_pread(File Filedes, uchar *Buffer, size_t Count, my_off_t offset,
#else
readbytes= pread(Filedes, Buffer, Count, offset);
#endif
-error = (readbytes != Count);
-if (error)
+if (readbytes != Count)
{
- my_errno= errno ? errno : -1;
+ my_errno= errno;
if (errno == 0 || (readbytes != (size_t) -1 &&
(MyFlags & (MY_NABP | MY_FNABP
my_errno= HA_ERR_FILE_TOO_SHORT;
@@ -82,6 +80,17 @@ size_t my_pread(File Filedes, uchar *Buffer, size_t Count,
my_off_t offset,
(int) readbytes));
continue; /* Interrupted */
}
+
+ /* Do a read retry if we didn't get enough data on first read */
+ if (readbytes != (size_t) -1 && readbytes != 0 &&
+ (MyFlags & MY_FULL_IO))
+ {
+Buffer+= readbytes;
+Count-= readbytes;
+save_count+= readbytes;
+continue;
eh, did you test your patch? I don't see how it could work without
offset+= readbytes;
it advance buffer pointer (as in correct version of my_read, we can not
advance both).
+ }
+
if (MyFlags & (MY_WME | MY_FAE | MY_FNABP))
{
if (readbytes == (size_t) -1)
@@ -97,8 +106,10 @@ size_t my_pread(File Filedes, uchar *Buffer, size_t Count,
my_off_t offset,
DBUG_RETURN(MY_FILE_ERROR); /* Return with error */
}
if (MyFlags & (MY_NABP | MY_FNABP))
- DBUG_RETURN(0); /* Read went ok; Return 0 */
-DBUG_RETURN(readbytes);/* purecov: inspected */
+ readbytes= 0; /* Read went ok; Return 0 */
+else
+ readbytes+= save_count;
+DBUG_RETURN(readbytes);
}
} /* my_pread */
diff --git a/mysys/my_read.c b/mysys/my_read.c
index 883a1c5fdc7..47f2d725f65 100644
--- a/mysys/my_read.c
+++ b/mysys/my_read.c
@@ -35,17 +35,16 @@
this is copied from 10.1 verbatim, I presume
Actually 10.3 but they looks like the same.
Regards,
Sergei
Chief Architect MariaDB
and secur...@mariadb.org
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] cd41d376d41: MDEV-16697: Fix difference between 32bit/windows and 64bit systems in allowed select nest level
Am 06.11.18 um 20:47 schrieb Sergei Golubchik: Hi, Oleksandr! Why did you do that? You wrote "Fix difference between 32bit/windows and 64bit systems", but to fix just that it would've been enough to change nesting_map to ulonglong. Using Bitmap<> you're basically preparing for any arbitrary >64 nesting depth. Is this your goal? What feature do you need it for? My thoughts was like this: 1) we need the same length 2) bitmap64 as efficient as ulonglong 3) why not use something more flexible On Nov 06, Oleksandr Byelkin wrote: revision-id: cd41d376d413d066f3d497a67d039515fd385a1c (versioning-1.0.5-36-gcd41d376d41) parent(s): 1748a31ae8d69e4939336f644f884e9de3039e7f author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2018-07-05 17:49:44 +0200 message: MDEV-16697: Fix difference between 32bit/windows and 64bit systems in allowed select nest level diff --git a/include/my_global.h b/include/my_global.h index 11d17ad146a..26078114464 100644 --- a/include/my_global.h +++ b/include/my_global.h @@ -984,7 +984,6 @@ typedef unsigned long my_off_t; TODO Convert these to use Bitmap class. */ typedef ulonglong table_map; /* Used for table bits in join */ -typedef ulong nesting_map; /* Used for flags of nesting constructs */ /* often used type names - opaque declarations */ typedef const struct charset_info_st CHARSET_INFO; diff --git a/sql/sql_lex.h b/sql/sql_lex.h --- a/sql/sql_lex.h +++ b/sql/sql_lex.h @@ -33,6 +33,10 @@ #include "sql_tvc.h" #include "item.h" +/* Used for flags of nesting constructs */ +#define SELECT_NESTING_MAP_SIZE 64 +typedef Bitmap nesting_map; + /* YACC and LEX Definitions */ Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 031efde365c: MDEV-16217: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date
Hi! Am 12.11.18 um 13:24 schrieb Sergei Golubchik: Hi, Oleksandr! On Nov 07, Oleksandr Byelkin wrote: revision-id: 031efde365c674dbdbaada95aa6d42a4274db438 (mariadb-10.2.18-65-g031efde365c) parent(s): 89f948c766721a26e110bc9da0ca5ebc20f65112 author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2018-11-07 14:29:47 +0100 message: MDEV-16217: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date - clean up DEFAULT() to work only with default value and correctly print itself. - fix of DBUG_ASSERT about fields read/write - fix of field marking for write based really on the thd->mark_used_columns flag diff --git a/sql/field.cc b/sql/field.cc index caa84dc9932..6cd8940a893 100644 --- a/sql/field.cc +++ b/sql/field.cc @@ -70,8 +70,21 @@ const char field_separator=','; #define BLOB_PACK_LENGTH_TO_MAX_LENGH(arg) \ ((ulong) ((1LL << MY_MIN(arg, 4) * 8) - 1)) -#define ASSERT_COLUMN_MARKED_FOR_READ DBUG_ASSERT(!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))) -#define ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED DBUG_ASSERT(is_stat_field || !table || (!table->write_set || bitmap_is_set(table->write_set, field_index) || (table->vcol_set && bitmap_is_set(table->vcol_set, field_index +// Column marked for read or the field set to read out or record[0] or [1] +#define ASSERT_COLUMN_MARKED_FOR_READ \ + DBUG_ASSERT(!table ||\ + (!table->read_set || \ + bitmap_is_set(table->read_set, field_index) || \ + (!(ptr >= table->record[0] && \ + ptr < table->record[0] + table->s->reclength + +#define ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED \ + DBUG_ASSERT(is_stat_field || !table || \ + (!table->write_set || \ + bitmap_is_set(table->write_set, field_index) || \ + (!(ptr >= table->record[0] && \ + ptr < table->record[0] + table->s->reclength))) || \ + (table->vcol_set && bitmap_is_set(table->vcol_set, field_index))) Do you need this ptr check in ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED ? I'd expect you only needing it in ASSERT_COLUMN_MARKED_FOR_READ. Appeared that yes, it is needed, because set_default uses save_in_field: #3 0x75b43412 in __GI___assert_fail (assertion=0x5663d230 "is_stat_field || !table || (!table->write_set || bitmap_is_set(table->write_set, field_index) || (table->vcol_set && bitmap_is_set(table->vcol_set, field_index)))", file=0x5663ceb0 "sql/field.cc", line=4205, function=0x5663faa0 "virtual int Field_long::store(longlong, bool)") at assert.c:101 #4 0x55d5629a in Field_long::store (this=0x7fffd4013888, nr=6, unsigned_val=false) at sql/field.cc:4205 #5 0x55da2939 in Item::save_in_field (this=0x7fffd4107ba8, field=0x7fffd4013888, no_conversions=false) at sql/item.cc:6386 #6 0x55d4f44f in Field::set_default (this=0x7fffd4013888) at sql/field.cc:2351 #7 0x55da9f3e in Item_default_value::calculate (this=0x7fffd4012858) at sql/item.cc:8876 [skip] ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 031efde365c: MDEV-16217: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date
Am 13.11.18 um 11:07 schrieb Sergei Golubchik: Hi, Oleksandr! On Nov 13, Oleksandr Byelkin wrote: Am 12.11.18 um 13:24 schrieb Sergei Golubchik: On Nov 07, Oleksandr Byelkin wrote: revision-id: 031efde365c674dbdbaada95aa6d42a4274db438 (mariadb-10.2.18-65-g031efde365c) parent(s): 89f948c766721a26e110bc9da0ca5ebc20f65112 author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2018-11-07 14:29:47 +0100 message: MDEV-16217: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date - clean up DEFAULT() to work only with default value and correctly print itself. - fix of DBUG_ASSERT about fields read/write - fix of field marking for write based really on the thd->mark_used_columns flag diff --git a/sql/field.cc b/sql/field.cc index caa84dc9932..6cd8940a893 100644 --- a/sql/field.cc +++ b/sql/field.cc @@ -70,8 +70,21 @@ const char field_separator=','; #define BLOB_PACK_LENGTH_TO_MAX_LENGH(arg) \ ((ulong) ((1LL << MY_MIN(arg, 4) * 8) - 1)) -#define ASSERT_COLUMN_MARKED_FOR_READ DBUG_ASSERT(!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))) -#define ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED DBUG_ASSERT(is_stat_field || !table || (!table->write_set || bitmap_is_set(table->write_set, field_index) || (table->vcol_set && bitmap_is_set(table->vcol_set, field_index +// Column marked for read or the field set to read out or record[0] or [1] +#define ASSERT_COLUMN_MARKED_FOR_READ \ + DBUG_ASSERT(!table ||\ + (!table->read_set || \ + bitmap_is_set(table->read_set, field_index) || \ + (!(ptr >= table->record[0] && \ + ptr < table->record[0] + table->s->reclength + +#define ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED \ + DBUG_ASSERT(is_stat_field || !table || \ + (!table->write_set || \ + bitmap_is_set(table->write_set, field_index) || \ + (!(ptr >= table->record[0] && \ + ptr < table->record[0] + table->s->reclength))) || \ + (table->vcol_set && bitmap_is_set(table->vcol_set, field_index))) Do you need this ptr check in ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED ? I'd expect you only needing it in ASSERT_COLUMN_MARKED_FOR_READ. Appeared that yes, it is needed, because set_default uses save_in_field: #3 0x75b43412 in __GI___assert_fail (assertion=0x5663d230 "is_stat_field || !table || (!table->write_set || bitmap_is_set(table->write_set, field_index) || (table->vcol_set && bitmap_is_set(table->vcol_set, field_index)))", file=0x5663ceb0 "sql/field.cc", line=4205, function=0x5663faa0 "virtual int Field_long::store(longlong, bool)") at assert.c:101 #4 0x55d5629a in Field_long::store (this=0x7fffd4013888, nr=6, unsigned_val=false) at sql/field.cc:4205 #5 0x55da2939 in Item::save_in_field (this=0x7fffd4107ba8, field=0x7fffd4013888, no_conversions=false) at sql/item.cc:6386 #6 0x55d4f44f in Field::set_default (this=0x7fffd4013888) at sql/field.cc:2351 #7 0x55da9f3e in Item_default_value::calculate (this=0x7fffd4012858) at sql/item.cc:8876 I see. What statement have caused it? select default(a),b from t1; assert/assert.c:89(__assert_fail_base)[0x7f260f59139a] /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7f260f591412] sql/field.cc:4206(Field_long::store(long long, bool))[0x563ded3fe29a] sql/item.cc:6386(Item::save_in_field(Field*, bool))[0x563ded44a939] sql/field.cc:2351(Field::set_default())[0x563ded3f744f] sql/item.cc:8877(Item_default_value::calculate())[0x563ded451f3e] sql/item.cc:8913(Item_default_value::send(Protocol*, String*))[0x563ded452096] sql/protocol.cc:979(Protocol::send_result_set_row(List*))[0x563ded0e775d] sql/sql_class.cc:2708(select_send::send_data(List&))[0x563ded168bc6] sql/sql_select.cc:19918(end_send(JOIN*, st_join_table*, bool))[0x563ded52] sql/sql_select.cc:18970(evaluate_join_record(JOIN*, st_join_table*, int))[0x563ded21fd15] sql/sql_select.cc:18750(sub_select(JOIN*, st_join_table*, bool))[0x563ded21f601] sql/sql_select.cc:18294(do_select(JOIN*, Procedure*))[0x563ded21eb88] sql/sql_select.cc:3609(JOIN::exec_inner())[0x563ded1f967c] sql/sql_select.cc:3405(JOIN::exec())[0x563ded1f8b28] sql/sql_select.cc:3806(mysql_select(THD*, TABLE_LIST*, unsigned int, List&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x563ded1f9cee] sql/s
Re: [Maria-developers] 49b63dcc048: MDEV-15073: Generic UDAF parser code in server for windows functions
Am 21.11.18 um 20:00 schrieb Sergei Golubchik:
Hi, Oleksandr!
On Nov 21, Oleksandr Byelkin wrote:
revision-id: 49b63dcc0482bcb0fc7f642b0c19c8e24740ab27
(mariadb-10.4.0-20-g49b63dcc048)
parent(s): b5ac863f1494920b5e7035c9dfa0ebfdaa50a15d
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2018-11-20 10:58:34 +0100
message:
MDEV-15073: Generic UDAF parser code in server for windows functions
Added support for usual agreggate UDF (UDAF)
Added remove() call support for more efficient window function processing
Added example of aggregate UDF with efficient windows function support
Looks good, see a couple of minor comments below.
I wouldn't extend UDF API, really. It's ancient and it should be removed
and replaced with a new plugin type, not extended.
But if you still want to do it make sure it's documented
https://mariadb.com/kb/en/user-defined-functions/
OK I will.
diff --git a/mysql-test/main/udf.test b/mysql-test/main/udf.test
index c3a25c6bcce..e72f8b219af 100644
--- a/mysql-test/main/udf.test
+++ b/mysql-test/main/udf.test
@@ -528,3 +528,62 @@ DROP FUNCTION METAPHON;
#INSERT INTO t1 (a) VALUES ('Hello');
#SELECT * FROM t1;
DROP TABLE t1;
+
+--echo
+--echo MDEV-15073: Generic UDAF parser code in server for windows functions
+--echo
use --echo #
OK
so that your echo commands would stand out in the result file.
currently they look like an output from some query and it's confusing.
The test itself is good.
diff --git a/sql/item_sum.cc b/sql/item_sum.cc
index 0e52b2988a3..d19645b5020 100644
--- a/sql/item_sum.cc
+++ b/sql/item_sum.cc
@@ -3235,6 +3235,25 @@ bool Item_udf_sum::add()
DBUG_RETURN(0);
}
+
+bool Item_udf_sum::supports_removal()
+{
+ DBUG_ENTER("Item_udf_sum::supports_remove");
+ DBUG_PRINT("info", ("support: %d", udf.supports_removal()));
+ DBUG_RETURN(udf.supports_removal());
+}
+
+
+void Item_udf_sum::remove()
+{
+ my_bool tmp_null_value;
+ DBUG_ENTER("Item_udf_sum::remove");
+ udf.remove(&tmp_null_value);
+ null_value= tmp_null_value;
+ DBUG_VOID_RETURN;
+}
+
+
void Item_udf_sum::cleanup()
{
/*
diff --git a/sql/item_sum.h b/sql/item_sum.h
index 1a21c257221..663dea1ed7b 100644
--- a/sql/item_sum.h
+++ b/sql/item_sum.h
@@ -574,7 +574,7 @@ class Item_sum :public Item_func_or_sum
virtual bool add()= 0;
virtual bool setup(THD *thd) { return false; }
- virtual bool supports_removal() const { return false; }
+ virtual bool supports_removal() { return false; }
why?
for UDF it will be defined for each instance (object) separately, it can
not be more one (const) function for the class.
virtual void remove() { DBUG_ASSERT(0); }
Regards,
Sergei
Chief Architect MariaDB
and secur...@mariadb.org
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] 7c782988845: MDEV-16240: Assertion `0' failed in row_sel_convert_mysql_key_to_innobase
Am 13.12.18 um 19:11 schrieb Sergei Golubchik:
Hi, Oleksandr!
On Dec 13, Oleksandr Byelkin wrote:
revision-id: 7c782988845dec9f0f26a539911f66ed8cecdf83
(mariadb-10.2.19-51-g7c782988845)
parent(s): ad3346dddf419aed3e5d16066471fd5022af1795
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2018-12-13 15:29:52 +0100
message:
MDEV-16240: Assertion `0' failed in row_sel_convert_mysql_key_to_innobase
Set table in row ID position mode before using this function.
---
mysql-test/r/multi_update_innodb.result | 40 +++
mysql-test/t/multi_update_innodb.test | 49 +
sql/sql_update.cc | 4 +++
3 files changed, 93 insertions(+)
diff --git a/mysql-test/r/multi_update_innodb.result
b/mysql-test/r/multi_update_innodb.result
index 5890fd24f5f..535c5a41d9f 100644
--- a/mysql-test/r/multi_update_innodb.result
+++ b/mysql-test/r/multi_update_innodb.result
@@ -151,3 +151,43 @@ create table t2 like t1;
insert into t2 select * from t1;
delete t1,t2 from t2,t1 where t1.a<'B' and t2.b=t1.b;
drop table t1,t2;
+#
+# MDEV-16240: Assertion `0' failed in
+# row_sel_convert_mysql_key_to_innobase
+#
+SET @save_sql_mode=@@sql_mode;
+set sql_mode='';
why sql_mode matters here?
to do not issue other error about type conversion.
+CREATE TABLE `t3` (
+`col_varchar_nokey` TIMESTAMP NOT NULL DEFAULT '-00-00 00:00:00' ON UPDATE
current_timestamp(),
+`col_varchar_key` datetime DEFAULT '2000-01-01 00:00:00' ON UPDATE
current_timestamp(),
+`col_int_nokey` TIMESTAMP NULL DEFAULT '2000-01-01 00:00:00',
+`pk` datetime NOT NULL DEFAULT '-00-00 00:00:00',
+`col_int_key` datetime DEFAULT current_timestamp(),
+PRIMARY KEY (`pk`),
+UNIQUE KEY `col_varchar_key` (`col_varchar_key`),
+KEY `col_int_key` (`col_int_key`)
+) ENGINE=InnoDB;
+INSERT INTO `t3` VALUES ('2018-05-18 15:08:07','2018-05-18
17:08:07','-00-00 00:00:00','-00-00 00:00:00','-00-00
00:00:00'),('-00-00 00:00:00','-00-00 00:00:00','1999-12-31
23:00:00','2002-07-03 23:04:40','-00-00 00:00:00');
+CREATE VIEW `v1` AS
+SELECT `t3`.`pk` AS `pk`,
+`t3`.`col_int_nokey` AS `col_int_nokey`,
+`t3`.`col_int_key` AS `col_int_key`,
+`t3`.`col_varchar_key` AS `col_varchar_key`,
+`t3`.`col_varchar_nokey` AS `col_varchar_nokey`
+FROM `t3`;
+CREATE TABLE `t4` (
+`col_varchar_nokey` datetime DEFAULT current_timestamp() ON UPDATE
current_timestamp(),
+`col_int_nokey` timestamp NULL DEFAULT NULL,
+`col_varchar_key` timestamp NULL DEFAULT '1999-12-31 23:00:00' ON UPDATE
current_timestamp(),
+`pk` int(11) NOT NULL,
+`col_int_key` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE
current_timestamp(),
+PRIMARY KEY (`pk`)
+) ENGINE=InnoDB;
+INSERT INTO `t4` VALUES ('2018-05-18 17:08:06','-00-00
00:00:00',NULL,1,'2018-05-18 15:08:06'),('2018-05-18 17:08:06','-00-00
00:00:00',NULL,2,'2018-05-18 15:08:06'),('2018-05-18 17:08:06','-00-00
00:00:00',NULL,3,'2018-05-18 15:08:06'),('-00-00 00:00:00','-00-00
00:00:00',NULL,1976,'-00-00 00:00:00'),('2018-05-18 17:08:06','-00-00
00:00:00',NULL,2000,'2018-05-18 15:08:06'),('2018-05-18 17:08:06','-00-00
00:00:00',NULL,2001,'2018-05-18 15:08:06'),('2018-05-18 17:08:06','-00-00
00:00:00',NULL,2002,'2018-05-18 15:08:06'),('2018-05-18 17:08:06','-00-00
00:00:00',NULL,2003,'2018-05-18 15:08:06'),('2018-05-18 17:08:06','-00-00
00:00:00',NULL,2004,'2018-05-18 15:08:06'),('2018-05-18 17:08:06','-00-00
00:00:00','2018-05-18 15:08:06',2005,'2018-05-18 15:08:06'),('2018-05-18
17:08:06','-00-00 00:00:00','2018-05-18 15:08:06',2018,'2018-05-18
15:08:06'),('2018-05-18 17:08:06','-00-00 00:00:00','2018-05-18
15:08:06',2019,'2018-05
-1
8 15:08:06'),('2018-05-18 17:08:06','-00-00 00:00:00','2018-05-18
15:08:06',2024,'2018-05-18 15:08:06'),('2018-05-18 17:08:06','-00-00
00:00:00','1999-12-31 23:00:00',2025,'2018-05-18 15:08:06'),('-00-00
00:00:00',NULL,'2018-05-18 15:08:06',2026,'2018-05-18 15:08:06'),('2018-05-18
17:08:07','-00-00 00:00:00','-00-00 00:00:00',2027,'-00-00
00:00:00');
+UPDATE `v1` t1, `t4` t2
+SET t1.`col_varchar_key` = 6452736 WHERE t1.`col_int_key` = 6272000;
+ERROR 23000: Duplicate entry '
Re: [Maria-developers] [Commits] bf951046e8d: MDEV-15296: wrong result with window function inside a subquery
Hi, Varun! This bug shows us whole class of the same problem in the code which slip of our scope during window function development. so please check and fix them (one or separate change-set as you wish). See comment below. Am 29.04.19 um 16:40 schrieb Varun: revision-id: bf951046e8df13702ee56e4e269ce5076e15407f (mariadb-10.2.23-99-gbf951046e8d) parent(s): 092602ac9b650f921ec5380866d17d740f0eedb4 author: Varun Gupta committer: Varun Gupta timestamp: 2019-04-29 20:07:47 +0530 message: MDEV-15296: wrong result with window function inside a subquery Window Functions were treated as a constant in a dependent tables less subquery. Made sure that the behaviour of window functions is same as the aggregate function for dependent tables less subquery. --- mysql-test/r/win.result | 17 + mysql-test/t/win.test | 10 ++ sql/item_subselect.cc | 1 + 3 files changed, 28 insertions(+) diff --git a/mysql-test/r/win.result b/mysql-test/r/win.result index 0ddffc551dc..b86f5b1fc16 100644 --- a/mysql-test/r/win.result +++ b/mysql-test/r/win.result @@ -3518,5 +3518,22 @@ rank() OVER (ORDER BY 1) ROW_NUMBER() OVER (ORDER BY (EXPORT_SET(5,'Y','N',',',4 1 3 drop table t1; # +# MDEV-15296: wrong result with window function inside a subquery +# +CREATE TABLE t1(i INT); +INSERT INTO t1 VALUES (1), (2); +EXPLAIN EXTENDED SELECT (SELECT SUM(i) OVER (partition BY i)) FROM t1; +id select_type table typepossible_keys key key_len ref rowsfilteredExtra +1 PRIMARY t1 ALL NULLNULLNULLNULL2 100.00 +2 DEPENDENT SUBQUERY NULLNULLNULLNULLNULLNULL NULLNULLNo tables used +Warnings: +Note 1276Field or reference 'test.t1.i' of SELECT #2 was resolved in SELECT #1 +Note 1003select <`test`.`t1`.`i`>((select sum(`test`.`t1`.`i`) over ( partition by `test`.`t1`.`i`))) AS `(SELECT SUM(i) OVER (partition BY i))` from `test`.`t1` +SELECT (SELECT SUM(i) OVER (partition BY i)) FROM t1; +(SELECT SUM(i) OVER (partition BY i)) +1 +2 +drop table t1; +# # End of 10.2 tests # diff --git a/mysql-test/t/win.test b/mysql-test/t/win.test index fd31e9d4bd9..6cc681cace4 100644 --- a/mysql-test/t/win.test +++ b/mysql-test/t/win.test @@ -2265,6 +2265,16 @@ insert into t1 values (1),(2),(3); SELECT rank() OVER (ORDER BY 1), ROW_NUMBER() OVER (ORDER BY (EXPORT_SET(5,'Y','N',',',4))) FROM t1; drop table t1; +--echo # +--echo # MDEV-15296: wrong result with window function inside a subquery +--echo # + +CREATE TABLE t1(i INT); +INSERT INTO t1 VALUES (1), (2); +EXPLAIN EXTENDED SELECT (SELECT SUM(i) OVER (partition BY i)) FROM t1; +SELECT (SELECT SUM(i) OVER (partition BY i)) FROM t1; +drop table t1; + --echo # --echo # End of 10.2 tests --echo # diff --git a/sql/item_subselect.cc b/sql/item_subselect.cc index 8cff8f3a5c4..95482364225 100644 --- a/sql/item_subselect.cc +++ b/sql/item_subselect.cc @@ -1138,6 +1138,7 @@ Item_singlerow_subselect::select_transformer(JOIN *join) !select_lex->table_list.elements && select_lex->item_list.elements == 1 && !select_lex->item_list.head()->with_sum_func && + !select_lex->item_list.head()->with_window_func && This case is definitely OK, but I also asked you to check other cases with with_sum_func, I do not see traces of it here so I did and it is my findings: Item_cache_wrapper::Item_cache_wrapper do not transfer with_window_func, is it impossible to have it here? (then better to put ASSERT) (same Item_cache_wrapper::get_tmp_table_item) Item_in_optimizer::fix_left, Item_in_optimizer::fix_fields, Item_func_interval::fix_length_and_dec do not transfer the flag also. ASSERT in Item_equal::fix_fields Item_func::get_tmp_table_item, Item_subselect::get_tmp_table_item impossible? than better put an ASSERT. Item_func constructors do not transfer the flag. Item_allany_subselect::cleanup reset. Item_singlerow_subselect::select_transformer, Item_in_subselect::single_value_transformer, Item_allany_subselect::transform_into_max_min, Item_exists_subselect::exists2in_processor, check_and_do_in_subquery_rewrites I doubts that window function allows the transformation is aggregate prohibit it. Item_in_subselect::create_single_in_to_exists_cond probably the same as aggregate. Item_in_subselect::create_row_in_to_exists_cond not sure if it is possible to have window functions hare but should be checked. st_select_lex::check_unrestricted_recursive, pushdown_cond_for_derived It looks like here also should be checked. /* We cant change name of Item_field or Item_ref, because it will prevent it's correct resolving, but we should save name of ___ commits mailing list comm...@mariadb.org https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits ___ Mailing list: https://launchpad.
Re: [Maria-developers] d7b274fa257: MDEV-16932: ASAN heap-use-after-free in my_charlen_utf8 / my_well_formed_char_length_utf8 on 2nd execution of SP with ALTER trying to add bad CHECK
Am 15.07.19 um 19:21 schrieb Sergei Golubchik:
Hi, Oleksandr!
A couple of minor comments, see below
On Jul 15, Oleksandr Byelkin wrote:
revision-id: d7b274fa257 (mariadb-10.2.25-63-gd7b274fa257)
parent(s): 64900e3d7c3
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2019-07-11 13:29:51 +0200
message:
MDEV-16932: ASAN heap-use-after-free in my_charlen_utf8 /
my_well_formed_char_length_utf8 on 2nd execution of SP with ALTER trying to add
bad CHECK
Make automatic name generation during execution (not prepare).
Check result of memory allocation operation.
diff --git a/sql/sql_table.cc b/sql/sql_table.cc
index 043cfaa..636fb9f427c 100644
--- a/sql/sql_table.cc
+++ b/sql/sql_table.cc
@@ -6205,6 +6210,10 @@ handle_if_exists_options(THD *thd, TABLE *table,
Alter_info *alter_info)
Virtual_column_info *check;
TABLE_SHARE *share= table->s;
uint c;
+
+if (fix_constraints_names(thd, &alter_info->check_constraint_list))
+ DBUG_RETURN(TRUE);
It's not very logical, I think, to generate constraint names in
handle_if_exists_options(), I'd rather move it out and put directly in
mysql_alter_table().
Absolutely agree. I tough to move but decided that it is too radical
change, but if you think so also I will do.
+
while ((check=it++))
{
if (!(check->flags & Alter_info::CHECK_CONSTRAINT_IF_NOT_EXISTS) &&
@@ -6232,10 +6241,44 @@ handle_if_exists_options(THD *thd, TABLE *table,
Alter_info *alter_info)
}
}
- DBUG_VOID_RETURN;
+ DBUG_RETURN(FALSE);
}
+static bool fix_constraints_names(THD *thd, List
+ *check_constraint_list)
+{
+ List_iterator it((*check_constraint_list));
+ Virtual_column_info *check;
+ uint nr= 1;
+ DBUG_ENTER("fix_constraints_names");
+ if (!check_constraint_list)
+DBUG_RETURN(FALSE);
+ // Prevent accessing freed memory during generating unique names
+ while ((check=it++))
+ {
+if (check->automatic_name)
+{
+ check->name.str= NULL;
+ check->name.length= 0;
+}
+ }
+ it.rewind();
+ // Grnerate unique names if needed
typo
ok
+ while ((check=it++))
+ {
+if (!check->name.length)
+{
+ check->automatic_name= TRUE;
+ if (make_unique_constraint_name(thd, &check->name,
+ check_constraint_list,
+ &nr))
+DBUG_RETURN(TRUE);
+}
+ }
+ DBUG_RETURN(FALSE);
I would remove the first while() at all and just do the second one till
the end:
bool ret= FALSE;
while ((check=it++))
if (check->automatic_name)
ret |= make_unique_constraint_name(...);
return ret;
Because thd->strmake() basically never fails, it doesn't make much sense
to optimize for a case when it does.
it is not optimisation it is just bug in error reporting, just several
month ago was fixing bug with the code like this, in any case it is
better to report error than coredump (it is especially important because
we do not have regular testing with low memory).
This code above assumes you set automatic_name=TRUE in
mysql_prepare_create_table().
+}
+
/**
Get Create_field object for newly created table by field index.
Regards,
Sergei
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] GSoC: On completing the MDEV-6017 (Add support for Indexes on Expressions)
Hi, Alexey! Am 01.10.19 um 14:29 schrieb Alexey Mogilyovkin: Hello, I would like to finish the task I was working on during GSoC. Nikita told me that there are some architectural questions to my code. Can you tell about them in more detail? Here you can find list of related MDEVs (as well as this itself) https://jira.mariadb.org/browse/MDEV-12326 , so you can check details of implementation of INSERT (it is closed, so should be pushed) ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
