- developers - lists.mariadb.org

Re: [Maria-developers] 326db1a: Mdev-14853 Grant does not work correctly when table contains...
by Sergei Golubchik 07 May '18

07 May '18

Hi, Sachin! On Apr 26, sachin wrote: > revision-id: 326db1a2aaa9b275a1a21a863e8cd2d9fa1b1d5f (mariadb-10.3.6-46-g326db1a) > parent(s): 9477a2a9ba17c0db362e2bb39d5048e369096f39 > author: Sachin Setiya > committer: Sachin Setiya > timestamp: 2018-04-26 12:47:25 +0530 > message: > > Mdev-14853 Grant does not work correctly when table contains... > SYSTEM_INVISIBLE or COMPLETELY_INVISIBLE > > This commit does multiple things to solve this mdev > 1st add field into the parameter of check_column_grant_in_table_ref, so that > we can find out field invisibility. > 2nd If field->invisible >= INVISIBLE_SYSTEM skip access check and simple > grant access. Looks ok. A couple of comments about the test: 1. I suppose now you can use system versioning to test system invisible fields, so there's no need to limit this test to debug-only builds. 2. please test a case when a user has *no* privileges on the table at all. To make sure he cannot select always-readable system invisible fields. and change the capitalization in the commit comment to say MDEV not Mdev - I suspect this was the reason why Jira didn't pick up your commit. Thanks! Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] 5651e72: MDEV-15465 Server crash or ASAN heap-use-after-free in Item_func_match::cleanup upon using FT search with partitioning.
by Sergei Golubchik 07 May '18

07 May '18

Hi, Alexey! On May 07, Alexey Botchkov wrote: > Yes, it is an issue in 5.5. > But we don't always fix bugs in the earliest version possible. > > Ok. Do i understand it right that the patch is ok to push into 5.5? Yes. > Should i then propagate the patch upt to 10.3 muself? No, don't bother. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] 5651e72: MDEV-15465 Server crash or ASAN heap-use-after-free in Item_func_match::cleanup upon using FT search with partitioning.
by Sergei Golubchik 06 May '18

06 May '18

Hi, Alexey! On May 03, Alexey Botchkov wrote: > revision-id: 5651e72b8dd20e29a4963723773ec6bcfac457ba (mariadb-10.3.6-102-g5651e72) > parent(s): 73a10cbcc5178ae5378abb821428d35d3276b4da > committer: Alexey Botchkov > timestamp: 2018-05-03 12:42:56 +0400 > message: > > MDEV-15465 Server crash or ASAN heap-use-after-free in Item_func_match::cleanup upon using FT search with partitioning. > > The Item_func_match::cleanup() uses table's internals so it's not safe > to call it after the close_thread_tables(). Let's call it in > st_select_lex::cleanup(). Oops. Agree, thanks. But why do you fix it in 10.3? Looks like a 5.5+ bug. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] cc0bc69: MDEV-15813 ASAN use-after-poison in hp_hashnr upon HANDLER READ on a
by Sergei Golubchik 06 May '18

06 May '18

Hi, Alexey! On May 06, Alexey Botchkov wrote: > revision-id: cc0bc69f2d28aace12487f930677abcdffa5ce97 (mariadb-10.3.6-102-gcc0bc69) > parent(s): 73a10cbcc5178ae5378abb821428d35d3276b4da > committer: Alexey Botchkov > timestamp: 2018-05-06 02:37:20 +0400 > message: > > MDEV-15813 ASAN use-after-poison in hp_hashnr upon HANDLER READ on a > versioned HEAP table. > > hp_rkey now returns an error if we try to use HASH key where it doesn't > work. > > diff --git a/sql/share/errmsg-utf8.txt b/sql/share/errmsg-utf8.txt > index c55ac4f..fcd20d8 100644 > --- a/sql/share/errmsg-utf8.txt > +++ b/sql/share/errmsg-utf8.txt > @@ -7915,3 +7915,5 @@ ER_UPDATED_COLUMN_ONLY_ONCE > eng "The column %`s.%`s cannot be changed more than once in a single UPDATE statement" > ER_EMPTY_ROW_IN_TVC > eng "Row with no elements is not allowed in table value constructor in this context" > +ER_KEY_DOESNT_SUPPORT > + eng "HASH index %`s does not support this operation" Use "%s index %`s does not support this operation" please. First parameter could be taken from handler::index_type(). By the way, check what happens when the index is a fulltext or rtree. Is it also a crash or this case is handled somehow? If it does, the same check should take care of HASH indexes, no need to do a separate solution for them. > diff --git a/storage/heap/hp_rkey.c b/storage/heap/hp_rkey.c > index 692e1a0..a7b81ae 100644 > --- a/storage/heap/hp_rkey.c > +++ b/storage/heap/hp_rkey.c > @@ -60,6 +60,14 @@ int heap_rkey(HP_INFO *info, uchar *record, int inx, const uchar *key, > } > else > { > + /* > + HASH key doesn't support search other than equality, > + and doesn't support prefix search. > + */ > + if (find_flag != HA_READ_KEY_EXACT || > + (1UL << share->keydef[inx].keysegs) != keypart_map + 1) > + DBUG_RETURN(my_errno= HA_ERR_KEY_DOESNT_SUPPORT); > + No, please, not here. The parent handler object knows index types, it knows index flags and it can return an error if the corresponding index flag is missing. No need to push this check down to the engine if the server can do it in, say, ha_index_read. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] MDEV-15813 ... HANDLER READ on a versioned HEAP table
by Sergei Golubchik 05 May '18

05 May '18

Hi, Alexey! On May 04, Alexey Botchkov wrote: > Hi, Sergei, guys. > > This bug iis more like a feature of the HASH indexes. > And i came upon other 'features' while experimenting. > > Firstly the 'range' queries like > HANDLER h READ `PRIMARY` < (5); > cannot be naturally handled by the HASH keys. Only equality queries > ...'PRIMARY' = (5); make sence. > And these 'range' queries just return wrong empty result. > I'd say we need to fire an error in this case. Do you agree? Yes. Like "HASH index `PRIMARY` does not support this operation" ? > Second problem - the SYSTEM VERSIONING. > It adds an extra column to the key, which makes this key virtually > useless. I think for the VERSIONING we should either replace the HASH > key with the RBTREE, or get the row_end data from the table after > getting records from the HASH. > What is your idea how to deal with this? row_end must be a part of every unique key, because uniqueness of current data should not be affected by historical, deleted, rows. In this particular use case, HANDLER is a low level command, it doesn't see high-level features like versioning. So, for HANDLER row_end is just a normal key part, should be used as HANDLER h READ `PRIMARY` = (5, '2038-01-19 03:14:07.999999'); Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] : GSoC Project Optimizer Trace
by Sergey Petrunia 04 May '18

04 May '18

Hi Zhzhzoo, Please find below some thoughts about the optimizer trace project * The MDEV for the optimizer trace task is https://jira.mariadb.org/browse/MDEV-6111. Let's keep it up to date with all the changes. * I think we should target MySQL-like functionality of optimizer_trace. At least, for the first milestone. We may decide to make some things better but working in a similar way to MySQL is a nice first goal. * MariaDB's optimizer trace will contain JSON and produce similar content to MySQL. However, MariaDB's optimizer is different, so one cannot expect that the JSON document will have exactly the same fields/objects/etc. (MariaDB' EXPLAIN FORMAT=JSON output doesn't match the one in MySQL, either. And in MySQL, the output varies across its versions.) * MySQL prints conditions with heavy over-quoting. Example: "original_condition": "((`A`.`a` = `B`.`a`) and ((`A`.`a` + `B`.`a`) < 10))", MariaDB has the code to print the condition without redundant quotes (see how EXPLAIN FORMAT=JSON does it). * I assume MySQL has some class for printing well-formed JSON documents. MariaDB also has one. It is in sql/my_json_writer.h, see class Json_writer. It handles printing into JSON, and also does pretty-printing. When I looked at the code last time, it did pretty-printing better than MySQL's code for EXPLAIN FORMAT=JSON did. It would be nice to use Json_writer for collecting optimizer trace output, too. (there is a caveat: Json_writer was written specifically for producing EXPLAIN FORMAT=JSON output so it may lack some features. You may need to extend it). BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MariaDB Developers Unconference in June
by Ian Gilfillan 03 May '18

03 May '18

Hi A reminder about the next MariaDB Developers Unconference, which will be held in Tampera, Finland, from 26 June to 29 June. This will be a four-day event; the first day focusing on new contributors, the 2nd and 3rd the regular Unconference sessions and discussions, and the 4th day on getting patches reviewed and implemented, taking advantage of the chance to have in-person discussions. Details, as well as where to register and how to suggest sessions, are at https://mariadb.org/2018-2-developers-unconference-in-finland/

1 0

Re: [Maria-developers] [External] Re: Questions regarding closing partitions in MDEV-11084
by Mattias Jonsson 30 Apr '18

30 Apr '18

Hi Holyfoot, Sergei and Jacob, Thank you for looking into this. Jacob there are no Jira ticket (that I am aware of) also I do see it as two different problems with the same source. 1) Spider engine does not handle opening/closing specific partitions (as I understand it currently relies on opening/closing all partitions at once in order). Currently this is a crashing bug! 2) MDEV-11084 makes explicit partition selection work like FLUSH TABLE, due to the closing partitions part. I think it would be nice if you could create tickets for those two issues (or at least for the first one). Regards Mattias On Thu, Apr 26, 2018 at 11:26 AM, Alexey Botchkov <holyfoot(a)mariadb.com> wrote: > No, there's no JIRA task for that problem. > So i guess you can create one :) > > Best regards. > HF > > On Thu, Apr 26, 2018 at 4:50 AM, Jacob Mathew <jacob.mathew(a)mariadb.com> > wrote: > >> Hi Mattias and Holyfoot, >> >> Is there a Jira bug for this problem? If not I can create a bug for it >> and assign it to Holyfoot. >> >> Thanks, >> Jacob >> >> Jacob B. Mathew >> Spider and Server Developer >> MariaDB Corporation >> +1 408 655 8999 (mobile) >> jacob.b.mathew (Skype) >> jacob.mathew(a)MariaDB.com >> >> >> On Tue, Apr 17, 2018 at 9:11 AM, Mattias Jonsson < >> mattias.jonsson(a)booking.com> wrote: >> >>> Hi Holyfoot, >>> >>> On Mon, Apr 16, 2018 at 3:38 PM, Alexey Botchkov <holyfoot(a)askmonty.org> >>> wrote: >>> > Hi, Mattias, guys! >>> > >>> > While investigating the crash, i'd like to discuss that >>> > >>> >> it seems to close partitions whenever it >>> >> is not used in a statement (i.e. require it to be reopened in the next >>> >> statement that would use another partition >>> > >>> > >>> > Yes, it does that, handling statements with the specified 'PARTITION' >>> > option. >>> > The patch supposed to solve the problem when there are too many >>> partitions >>> > opened, >>> > so i think it must close the unused partitions sometime. >>> > No, it doesn't have to happen that often. I planned to check the >>> > table_open_cache >>> > variable before the forced close. But decided not to do that initially >>> - as >>> > it simplified testing, >>> > and i thought if someone uses the PARTITION option, he would stick to >>> using >>> > this partition >>> > anyway. And i forgot about that issue. >>> >>> The reason for not closing partitions in this case is that it turns >>> the 'SELECT col FROM t PARTITION(p)' almost into a 'FLUSH TABLES t' >>> which is kind of unexpected. >>> I did a test mixing PK selects with and without 'PARTITION (p)' clause >>> and that shows it will close all but 1 partition and then (re)open all >>> but 1 partition. >>> >>> Think of the case when a server runs in production with a heavily >>> partitioned table serving simple PK queries and then someone runs a >>> query with explicit PARTITION selection, then it will introduce a >>> short stall. First for the query itself (closing all but 1 partitions) >>> and then for the next simple PK query using the same table (opening >>> all but 1 partition). >>> >>> As I read the bug report: the reporter wants to avoid opening all >>> partitions. Not that it keeps the partitions open in the table open >>> cache (which is an issue on the architectural level of partitioning >>> not really fitting into the open table cache). >>> >>> I attached a diff with the test and results (I also added handler >>> status variables to show my point). The diff is against >>> b4a2baffa82e5c07b96a1c752228560dcac1359b. >>> >>> Here is the part of the result file that shows what I mean with extra >>> comments prepended by MJ>: >>> CREATE TABLE t1 (a int PRIMARY KEY) >>> ENGINE = InnoDB >>> PARTITION BY HASH (a) PARTITIONS 1000; >>> INSERT INTO t1 VALUES (0), (1), (2), (3); >>> FLUSH STATUS; >>> >>> SELECT a FROM t1 PARTITION(p0) WHERE a = 0; >>> a >>> 0 >>> SHOW SESSION STATUS >>> WHERE VARIABLE_NAME LIKE 'HANDLER_%' AND VALUE > 0; >>> Variable_name Value >>> MJ> Here it closes all but one partitions. >>> Handler_close 999 >>> >>> SELECT a FROM t1 WHERE a = 0; >>> a >>> 0 >>> SHOW SESSION STATUS >>> WHERE VARIABLE_NAME LIKE 'HANDLER_%' AND VALUE > 0; >>> Variable_name Value >>> Handler_close 1000 >>> Handler_external_lock 2006 >>> MJ> and here it re-opens those 'all but one' partitions. >>> Handler_open 999 >>> >>> >>> Regards >>> Mattias >>> > >>> > >>> > Best regards. >>> > HF >>> > >>> > >>> > >>> > >>> > 13.04.2018 19:07, Mattias Jonsson wrote: >>> >> >>> >> Hi MariaDB Devs, >>> >> >>> >> I tried to evaluate spider engine and found an issue where it crashes, >>> >> most likely due to MDEV-11084 (Stacktrace and reproducible test case >>> >> attached). >>> >> >>> >> That also leads me to wonder about the performance for partitioned >>> >> tables after MDEV-11084, when it seems to close partitions whenever it >>> >> is not used in a statement (i.e. require it to be reopened in the next >>> >> statement that would use another partition, effectively not using the >>> >> open table cache). >>> >> >>> >> I cannot see anything mentioned in the final commit message hinting on >>> >> that it closes partitions not used in the current query, but in the >>> >> previous patches it was mentioned without any reason. >>> >> >>> >> Why does it close the already opened partitions? >>> >> https://github.com/MariaDB/server/blob/10.3/sql/ha_partition.cc#L8365 >>> >> >>> >> I would not mind opening the partitions only when they are to be used >>> >> (even though there are engines that need to be tested more), but >>> >> closing them makes no sense to me performance wise. Also notice that >>> >> the partitions first will be put back into the open table cache and >>> >> then on the next query the non-used partitions will be closed and the >>> >> needed ones be (re)-opened. >>> >> >>> >> Regards >>> >> Mattias Jonsson >>> > >>> > >>> > >>> > >>> >> >> > -- Mattias Jonsson IT Team Lead - Development Booking.com B.V. Herengracht 597 Amsterdam 1017 CE Netherlands Direct +31207125646 [image: Booking.com] <http://www.booking.com/> The world's #1 accommodation site 43 languages, 198+ offices worldwide, 120,000+ global destinations, 1,550,000+ room nights booked every day No booking fees, best price always guaranteed Subsidiary of Booking Holdings Inc. (NASDAQ: BKNG)

3 4

Re: [Maria-developers] [Commits] 326db1a: Mdev-14853 Grant does not work correctly when table contains...
by Vicențiu Ciorbaru 26 Apr '18

26 Apr '18

Hi Sachin! Did you run this test on embedded server? Usually grant related tests require some form of not_embedded.inc include. (check roles suite for examples) Vicentiu On Thu, 26 Apr 2018 at 00:20 sachin <sachin.setiya(a)mariadb.com> wrote: > revision-id: 326db1a2aaa9b275a1a21a863e8cd2d9fa1b1d5f > (mariadb-10.3.6-46-g326db1a) > parent(s): 9477a2a9ba17c0db362e2bb39d5048e369096f39 > author: Sachin Setiya > committer: Sachin Setiya > timestamp: 2018-04-26 12:47:25 +0530 > message: > > Mdev-14853 Grant does not work correctly when table contains... > SYSTEM_INVISIBLE or COMPLETELY_INVISIBLE > > This commit does multiple things to solve this mdev > 1st add field into the parameter of check_column_grant_in_table_ref, so > that > we can find out field invisibility. > 2nd If field->invisible >= INVISIBLE_SYSTEM skip access check and simple > grant access. > > --- > mysql-test/main/invisible_field_grant.result | 111 > +++++++++++++++++++++++++++ > mysql-test/main/invisible_field_grant.test | 77 +++++++++++++++++++ > sql/sp_rcontext.cc | 9 ++- > sql/sql_acl.cc | 11 ++- > sql/sql_acl.h | 2 +- > sql/sql_base.cc | 4 +- > 6 files changed, 206 insertions(+), 8 deletions(-) > > diff --git a/mysql-test/main/invisible_field_grant.result > b/mysql-test/main/invisible_field_grant.result > new file mode 100644 > index 0000000..c3ccbb1 > --- /dev/null > +++ b/mysql-test/main/invisible_field_grant.result > @@ -0,0 +1,111 @@ > +set @old_debug= @@debug_dbug; > +create user user_1; > +show grants for user_1; > +Grants for user_1@% > +GRANT USAGE ON *.* TO 'user_1'@'%' > +# create user > +create database d; > +use d; > + > +#System_Invisible > +set debug_dbug= "+d,test_pseudo_invisible"; > +create table t1(a int); > +set debug_dbug=@old_debug; > +insert into t1 values(1); > +select a,invisible from t1; > +a invisible > +1 9 > +grant insert(a) on t1 to user_1; > +grant update(a) on t1 to user_1; > +grant select(a) on t1 to user_1; > +grant delete on t1 to user_1; > +connect con1, localhost, user_1,,test; > +connection con1; > +select user(); > +user() > +user_1@localhost > +use d; > +select * from t1; > +a > +1 > +insert into t1 values(2); > +select * from t1; > +a > +1 > +2 > +insert into t1(a) values(3); > +select * from t1; > +a > +1 > +2 > +3 > +select invisible,a from t1; > +invisible a > +9 1 > +9 2 > +9 3 > +delete from t1 where a =1; > +update t1 set a=1 where a=3; > +select * from t1; > +a > +2 > +1 > +disconnect con1; > + > +#Cleanup > +connection default; > +drop table t1; > +REVOKE ALL PRIVILEGES, GRANT OPTION FROM user_1; > + > +#Completely Invisible > +set debug_dbug= "+d,test_completely_invisible"; > +create table t1(a int); > +insert into t1 values(1); > +select a,invisible from t1; > +a invisible > +1 9 > +set debug_dbug=@old_debug; > +grant insert(a) on t1 to user_1; > +grant update(a) on t1 to user_1; > +grant select(a) on t1 to user_1; > +grant delete on t1 to user_1; > +connect con1, localhost, user_1,,test; > +connection con1; > +select user(); > +user() > +user_1@localhost > +use d; > +select * from t1; > +a > +1 > +insert into t1 values(2); > +select * from t1; > +a > +1 > +2 > +insert into t1(a) values(3); > +select * from t1; > +a > +1 > +2 > +3 > +select invisible,a from t1; > +ERROR 42S22: Unknown column 'invisible' in 'field list' > +delete from t1 where a =1; > +update t1 set a=1 where a=3; > +select * from t1; > +a > +2 > +1 > +disconnect con1; > + > +#Final Cleanup > +connection default; > +set debug_dbug= "+d,test_completely_invisible"; > +select a,invisible from t1; > +a invisible > +2 9 > +1 9 > +drop user user_1; > +drop database d; > +set @old_debug= @@debug_dbug; > diff --git a/mysql-test/main/invisible_field_grant.test > b/mysql-test/main/invisible_field_grant.test > new file mode 100644 > index 0000000..0d627e5 > --- /dev/null > +++ b/mysql-test/main/invisible_field_grant.test > @@ -0,0 +1,77 @@ > +--source include/have_debug.inc > +##TEST for invisible coloumn level 2 > +set @old_debug= @@debug_dbug; > +create user user_1; > +show grants for user_1; > +--echo # create user > +create database d; > +use d; > + > +--echo > +--echo #System_Invisible > +set debug_dbug= "+d,test_pseudo_invisible"; > +create table t1(a int); > +set debug_dbug=@old_debug; > +insert into t1 values(1); > +select a,invisible from t1; > +grant insert(a) on t1 to user_1; > +grant update(a) on t1 to user_1; > +grant select(a) on t1 to user_1; > +grant delete on t1 to user_1; > +connect (con1, localhost, user_1,,test); > +connection con1; > +select user(); > +use d; > +select * from t1; > +insert into t1 values(2); > +select * from t1; > +insert into t1(a) values(3); > +select * from t1; > +select invisible,a from t1; > +delete from t1 where a =1; > +update t1 set a=1 where a=3; > +select * from t1; > +disconnect con1; > +--source include/wait_until_disconnected.inc > + > +--echo > +--echo #Cleanup > +--connection default > +drop table t1; > +REVOKE ALL PRIVILEGES, GRANT OPTION FROM user_1; > + > +--echo > +--echo #Completely Invisible > +set debug_dbug= "+d,test_completely_invisible"; > +create table t1(a int); > +insert into t1 values(1); > +select a,invisible from t1; > +set debug_dbug=@old_debug; > +grant insert(a) on t1 to user_1; > +grant update(a) on t1 to user_1; > +grant select(a) on t1 to user_1; > +grant delete on t1 to user_1; > +connect (con1, localhost, user_1,,test); > +connection con1; > +select user(); > +use d; > +select * from t1; > +insert into t1 values(2); > +select * from t1; > +insert into t1(a) values(3); > +select * from t1; > +--error ER_BAD_FIELD_ERROR > +select invisible,a from t1; > +delete from t1 where a =1; > +update t1 set a=1 where a=3; > +select * from t1; > +disconnect con1; > +--source include/wait_until_disconnected.inc > +--echo > +--echo #Final Cleanup > +connection default; > +set debug_dbug= "+d,test_completely_invisible"; > +select a,invisible from t1; > +drop user user_1; > +drop database d; > +set @old_debug= @@debug_dbug; > diff --git a/sql/sp_rcontext.cc b/sql/sp_rcontext.cc > index 2e9ae23..dc103fa 100644 > --- a/sql/sp_rcontext.cc > +++ b/sql/sp_rcontext.cc > @@ -196,11 +196,12 @@ bool sp_rcontext::init_var_table(THD *thd, > */ > static inline bool > check_column_grant_for_type_ref(THD *thd, TABLE_LIST *table_list, > - const char *str, size_t length) > + const char *str, size_t length, > + Field *fld) > { > #ifndef NO_EMBEDDED_ACCESS_CHECKS > table_list->table->grant.want_privilege= SELECT_ACL; > - return check_column_grant_in_table_ref(thd, table_list, str, length); > + return check_column_grant_in_table_ref(thd, table_list, str, length, > fld); > #else > return false; > #endif > @@ -238,7 +239,7 @@ bool Qualified_column_ident::resolve_type_ref(THD > *thd, Column_definition *def) > { > if (!(rc= check_column_grant_for_type_ref(thd, table_list, > m_column.str, > - m_column.length))) > + m_column.length, src))) > { > *def= Column_definition(thd, src, NULL/*No defaults,no > constraints*/); > def->flags&= (uint) ~NOT_NULL_FLAG; > @@ -302,7 +303,7 @@ bool Table_ident::resolve_table_rowtype_ref(THD *thd, > LEX_CSTRING tmp= src[0]->field_name; > Spvar_definition *def; > if ((rc= check_column_grant_for_type_ref(thd, table_list, > - tmp.str, tmp.length)) || > + tmp.str, > tmp.length,src[0])) || > (rc= !(src[0]->field_name.str= thd->strmake(tmp.str, > tmp.length))) || > (rc= !(def= new (thd->mem_root) Spvar_definition(thd, *src)))) > break; > diff --git a/sql/sql_acl.cc b/sql/sql_acl.cc > index de4e201..1c154a1 100644 > --- a/sql/sql_acl.cc > +++ b/sql/sql_acl.cc > @@ -7775,6 +7775,8 @@ bool check_grant_column(THD *thd, GRANT_INFO *grant, > table_ref table reference where to check the field > name name of field to check > length length of name > + fld use fld object to check invisibility when it is > + not 0, not_found_field, view_ref_found > > DESCRIPTION > Check the access rights to a column depending on the type of table > @@ -7789,13 +7791,17 @@ bool check_grant_column(THD *thd, GRANT_INFO > *grant, > */ > > bool check_column_grant_in_table_ref(THD *thd, TABLE_LIST * table_ref, > - const char *name, size_t length) > + const char *name, size_t length, > + Field *fld) > { > GRANT_INFO *grant; > const char *db_name; > const char *table_name; > Security_context *sctx= table_ref->security_ctx ? > table_ref->security_ctx : thd->security_ctx; > + if (fld && fld != not_found_field && fld != view_ref_found > + && fld->invisible >= INVISIBLE_SYSTEM) > + return false; > > if (table_ref->view || table_ref->field_translation) > { > @@ -7871,6 +7877,9 @@ bool check_grant_all_columns(THD *thd, ulong > want_access_arg, > > for (; !fields->end_of_fields(); fields->next()) > { > + if (fields->field() && > + fields->field()->invisible >= INVISIBLE_SYSTEM) > + continue; > LEX_CSTRING *field_name= fields->name(); > > if (table_name != fields->get_table_name()) > diff --git a/sql/sql_acl.h b/sql/sql_acl.h > index a608ef0..6da7d4d 100644 > --- a/sql/sql_acl.h > +++ b/sql/sql_acl.h > @@ -239,7 +239,7 @@ bool check_grant_column (THD *thd, GRANT_INFO *grant, > const char *db_name, const char *table_name, > const char *name, size_t length, > Security_context *sctx); > bool check_column_grant_in_table_ref(THD *thd, TABLE_LIST * table_ref, > - const char *name, size_t length); > + const char *name, size_t length, > Field *fld); > bool check_grant_all_columns(THD *thd, ulong want_access, > Field_iterator_table_ref *fields); > bool check_grant_routine(THD *thd, ulong want_access, > diff --git a/sql/sql_base.cc b/sql/sql_base.cc > index 0081365..383341c 100644 > --- a/sql/sql_base.cc > +++ b/sql/sql_base.cc > @@ -5880,7 +5880,7 @@ find_field_in_table_ref(THD *thd, TABLE_LIST > *table_list, > #ifndef NO_EMBEDDED_ACCESS_CHECKS > /* Check if there are sufficient access rights to the found field. */ > if (check_privileges && > - check_column_grant_in_table_ref(thd, *actual_table, name, length)) > + check_column_grant_in_table_ref(thd, *actual_table, name, length, > fld)) > fld= WRONG_GRANT; > else > #endif > @@ -6057,7 +6057,7 @@ find_field_in_tables(THD *thd, Item_ident *item, > #ifndef NO_EMBEDDED_ACCESS_CHECKS > /* Check if there are sufficient access rights to the found field. > */ > if (found && check_privileges && > - check_column_grant_in_table_ref(thd, table_ref, name, length)) > + check_column_grant_in_table_ref(thd, table_ref, name, length, > found)) > found= WRONG_GRANT; > #endif > } > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 1

Re: [Maria-developers] Questions regarding closing partitions in MDEV-11084
by Alexey Botchkov 26 Apr '18

26 Apr '18

Hi, Mattias, guys! While investigating the crash, i'd like to discuss that > it seems to close partitions whenever it > is not used in a statement (i.e. require it to be reopened in the next > statement that would use another partition Yes, it does that, handling statements with the specified 'PARTITION' option. The patch supposed to solve the problem when there are too many partitions opened, so i think it must close the unused partitions sometime. No, it doesn't have to happen that often. I planned to check the table_open_cache variable before the forced close. But decided not to do that initially - as it simplified testing, and i thought if someone uses the PARTITION option, he would stick to using this partition anyway. And i forgot about that issue. Best regards. HF 13.04.2018 19:07, Mattias Jonsson wrote: > Hi MariaDB Devs, > > I tried to evaluate spider engine and found an issue where it crashes, > most likely due to MDEV-11084 (Stacktrace and reproducible test case > attached). > > That also leads me to wonder about the performance for partitioned > tables after MDEV-11084, when it seems to close partitions whenever it > is not used in a statement (i.e. require it to be reopened in the next > statement that would use another partition, effectively not using the > open table cache). > > I cannot see anything mentioned in the final commit message hinting on > that it closes partitions not used in the current query, but in the > previous patches it was mentioned without any reason. > > Why does it close the already opened partitions? > https://github.com/MariaDB/server/blob/10.3/sql/ha_partition.cc#L8365 > > I would not mind opening the partitions only when they are to be used > (even though there are engines that need to be tested more), but > closing them makes no sense to me performance wise. Also notice that > the partitions first will be put back into the open table cache and > then on the next query the non-used partitions will be closed and the > needed ones be (re)-opened. > > Regards > Mattias Jonsson

3 2