- developers - lists.mariadb.org

Re: [Maria-developers] Observation for CHECK_CONSTRAINTS MDEV 14474
by Vicențiu Ciorbaru 14 Apr '18

14 Apr '18

Hi Anel! I've reviewed your patch and generally things look good. You do some good analysis usually and I think we should highlight your work to the broader developer scene. I've thus CC'ed this email to the maria-developers mailing list. This gives us a chance to get feedback from outside, particularly as this feature is of general interest to the community. Please include the .result files in future versions as it makes reviewing a lot easier. Serg: coding style and implementation aside, I'll do the review on that bit, please have a look at Anel's patch and suggest if you think the current table header for I_S.check_constraints is good enough for our needs or if you have more input on this task. Relevant bit: +ST_FIELD_INFO check_constraints_fields_info[]= +{ + {"CONSTRAINT_CATALOG", FN_REFLEN, MYSQL_TYPE_STRING, 0, 0, 0, OPEN_FULL_TABLE}, + {"CONSTRAINT_SCHEMA", NAME_CHAR_LEN, MYSQL_TYPE_STRING, 0, 0, 0, + OPEN_FULL_TABLE}, + {"CONSTRAINT_NAME", NAME_CHAR_LEN, MYSQL_TYPE_STRING, 0, 0, 0, + OPEN_FULL_TABLE}, + {"TABLE_SCHEMA", NAME_CHAR_LEN, MYSQL_TYPE_STRING, 0, 0, 0, OPEN_FULL_TABLE}, + {"TABLE_NAME", NAME_CHAR_LEN, MYSQL_TYPE_STRING, 0, 0, 0, OPEN_FULL_TABLE}, + {"CHECK_CLAUSE", NAME_CHAR_LEN, MYSQL_TYPE_STRING, 0, 0, 0, + OPEN_FULL_TABLE}, + {0, 0, MYSQL_TYPE_STRING, 0, 0, 0, SKIP_OPEN_TABLE} +}; Vicențiu On Thu, 29 Mar 2018 at 12:01 Anel Husakovic <anel(a)mariadb.org> wrote: > Hi Vin, > > I'm pleased to announce my new patch prototype for MDEV 14474 where are > implemented field and table constraints: > > https://github.com/an3l/server/commit/f92fd77d2695be52faf280245faa014c44617… > > According to the standard there are only 4 column to represent. > CONSTRAINT_CATALOG, CONSTRAINT_SCHEMA, CONSTRAINT_NAME,CHECK_CLAUSE > But because Serg mentioned that alternative would be to change > *information_schema.table_constraints* with adding only 1 column ( > *check_clause*) I also used 2 additional columns which are represented > also in *table_constraints *and they are TABLE_SHEMA , TABLE_NAME. > > Function of interest is: get_check_constraints_record > > Also I added 2 test cases: > > One that works with only 1 table: MDEV14474-one_table_play.test > <https://github.com/an3l/server/commit/f92fd77d2695be52faf280245faa014c44617…> > Second that works with more tables: MDEV14474-I_S_check_constraint.test > <https://github.com/an3l/server/commit/f92fd77d2695be52faf280245faa014c44617…> > > Last night I had a problem with field constraints. > As a reference I used only way how currently all check constraints are > shown and its obtained via* show create table t;* > > Bellow is shown that field constraints were not visible as well as that > name used for them is *NULL*, at least this is how *show create table* > represented them ( there is no way to give a name to a field constraint* > for example: f int constraint name check(f<0)*). According to my opinion, > because this constraint belongs to the field, it should be also called as a > name of a field and not NULL. > As an argument to my opinion here is mariadb kb > https://mariadb.com/kb/en/library/constraint/ > Please take a look at *constraint **name*, which is field constraint and > error message. > > INSERT INTO t2(name, start_date, end_date) VALUES('Io', '2003-12-15', '2014-11-09');ERROR 4022 (23000): CONSTRAINT `name` failed for `test`.`t2` > > If the name of constraint = name of the field , than definitely it is not > consistent with* show create table* output, and *show create table* > output *needs to be changed*, , but this is question that I would like > to discuss with you ?! > > When you try to use show create table x > [image: image.png] > > > I'm waiting on your reply for global temporary tables as well as > check_constraints and how to proceed further > > *Not understand yet a concept*: > > In *sql/table.h* > There is a struct* st_schema_table *which has fill data and process data. > > How they work, and how to use that on other database for example PSI. > > Regards, > > Anel >

2 1

Re: [Maria-developers] [Commits] a74e3ef17e7: MDEV-14551 Can't find record in table on multi-table update with ORDER BY
by Sergey Petrunia 13 Apr '18

13 Apr '18

Hi Serg, Please find some cosmetic input below. (additionally, we've found a failing example while chatting) On Tue, Apr 10, 2018 at 02:10:17PM +0200, serg(a)mariadb.org wrote: > revision-id: a74e3ef17e7a8693d68001290a8d91b5b206804d (mariadb-10.3.5-138-ga74e3ef17e7) > parent(s): 9bd3af97dffa411657879bbdfd4dfef38c99f7cc > author: Sergei Golubchik > committer: Sergei Golubchik > timestamp: 2018-04-10 14:09:17 +0200 > message: > > MDEV-14551 Can't find record in table on multi-table update with ORDER BY ... > diff --git a/mysql-test/main/multi_update.test b/mysql-test/main/multi_update.test > index 5feebe87a5a..96e78dab82b 100644 > --- a/mysql-test/main/multi_update.test > +++ b/mysql-test/main/multi_update.test > @@ -914,3 +914,14 @@ update t1 set c1=NULL; > update t1, t2 set t1.c1=t2.c3 where t1.c3=t2.c3 order by t1.c3 desc limit 2; > select * from t1; > drop table t1, t2; > + > +# > +# MDEV-14551 Can't find record in table on multi-table update with ORDER BY > +# > +CREATE TABLE t1 (i INT) ENGINE=MEMORY; > +INSERT t1 VALUES (1),(2); > +CREATE TABLE t2 (f INT) ENGINE=MyISAM; > +INSERT t2 VALUES (1),(2); > +UPDATE t1, t2 SET f = 126 ORDER BY f LIMIT 2; > +SELECT * FROM t2; > +DROP TABLE t1, t2; > diff --git a/sql/item.h b/sql/item.h > index 9574bdc63bf..e391e7810c4 100644 > --- a/sql/item.h > +++ b/sql/item.h > @@ -2023,6 +2023,7 @@ class Item: public Value_source, > { > marker &= ~EXTRACTION_MASK; > } > + virtual TABLE *rowid_table() const { return 0; } I am concerned about this approach bloating class Item's vtable. There is (and likely will ever be) only one class with a different implementation, the check for this is made only in one place - why not check Item's type() or functype(), etc? > }; > > MEM_ROOT *get_thd_memroot(THD *thd); > diff --git a/sql/item_strfunc.cc b/sql/item_strfunc.cc > index c6b0ae7fba8..9097ffca867 100644 > --- a/sql/item_strfunc.cc > +++ b/sql/item_strfunc.cc > @@ -5204,3 +5204,23 @@ String *Item_func_dyncol_list::val_str(String *str) > my_free(names); > return NULL; > } > + > +Item_temptable_rowid::Item_temptable_rowid(TABLE *table_arg) > + : Item_str_func(table_arg->in_use), table(table_arg) > +{ > + max_length= table->file->ref_length; > +} > + > +void Item_temptable_rowid::fix_length_and_dec() > +{ > + used_tables_cache= table->map; > + const_item_cache= false; > +} > + > +String *Item_temptable_rowid::val_str(String *str) > +{ > + if (!((null_value= table->null_row))) > + table->file->position(table->record[0]); > + str_value.set((char*)(table->file->ref), max_length, &my_charset_bin); > + return &str_value; > +} > diff --git a/sql/item_strfunc.h b/sql/item_strfunc.h > index 18cda491efd..49de5568696 100644 > --- a/sql/item_strfunc.h > +++ b/sql/item_strfunc.h > @@ -1748,5 +1748,20 @@ class Item_func_dyncol_list: public Item_str_func > { return get_item_copy<Item_func_dyncol_list>(thd, this); } > }; > > -#endif /* ITEM_STRFUNC_INCLUDED */ Please add a note that this is not the "_rowid" that we support in the parser. > +class Item_temptable_rowid :public Item_str_func > +{ > + TABLE *table; > +public: > + Item_temptable_rowid(TABLE *table_arg); > + const Type_handler *type_handler() const { return &type_handler_string; } > + Field *create_tmp_field(bool group, TABLE *table) > + { return create_table_field_from_handler(table); } > + String *val_str(String *str); > + const char *func_name() const { return "<rowid>"; } > + void fix_length_and_dec(); > + Item *get_copy(THD *thd) > + { return get_item_copy<Item_temptable_rowid>(thd, this); } > + TABLE *rowid_table() const { return table; } > +}; > > +#endif /* ITEM_STRFUNC_INCLUDED */ ... > diff --git a/sql/sql_select.cc b/sql/sql_select.cc > index 796ea569e64..22301319680 100644 > --- a/sql/sql_select.cc > +++ b/sql/sql_select.cc > @@ -2650,6 +2650,21 @@ bool JOIN::add_having_as_table_cond(JOIN_TAB *tab) > } > > > +bool JOIN::add_fields_for_current_rowid(JOIN_TAB *cur, List<Item> *table_fields) I think ths is actually "current rowids", in plural. As the loop shows, there are multiple current rowids (from different tables). > +{ > + for (JOIN_TAB *tab=join_tab; tab < cur; tab++) Please add a comment: this will not walk into semi-join materialization nests but this is ok because we will never need to save current rowids for those. > + { > + if (!tab->keep_current_rowid) > + continue; > + Item *item= new (thd->mem_root) Item_temptable_rowid(tab->table); > + item->fix_fields(thd, 0); > + table_fields->push_back(item, thd->mem_root); > + cur->tmp_table_param->func_count++; > + } > + return 0; > +} > + > + > /** > Set info for aggregation tables > > diff --git a/sql/sql_select.h b/sql/sql_select.h > index f8911fbba01..1da87bb9d50 100644 > --- a/sql/sql_select.h > +++ b/sql/sql_select.h > @@ -1438,6 +1438,9 @@ class JOIN :public Sql_alloc > > enum { QEP_NOT_PRESENT_YET, QEP_AVAILABLE, QEP_DELETED} have_query_plan; > > + // if keep_current_rowid=true, whether they should be saved in temporary table > + bool tmp_table_keep_current_rowid; Same input as with add_fields_for_current_rowid - use plural. > + > /* > Additional WHERE and HAVING predicates to be considered for IN=>EXISTS > subquery transformation of a JOIN object. > diff --git a/sql/sql_union.cc b/sql/sql_union.cc > index 0149c2848c2..0e29f817e56 100644 > --- a/sql/sql_union.cc > +++ b/sql/sql_union.cc > @@ -507,14 +507,14 @@ void select_union_recursive::cleanup() > bool select_union_direct::change_result(select_result *new_result) > { > result= new_result; > - return (result->prepare(unit->types, unit) || result->prepare2()); > + return (result->prepare(unit->types, unit) || result->prepare2(0)); Do we really continue to use '0' when 'NULL' should be used? I prefer "NULL". > } > > > bool select_union_direct::postponed_prepare(List<Item> &types) > { > if (result != NULL) > - return (result->prepare(types, unit) || result->prepare2()); > + return (result->prepare(types, unit) || result->prepare2(0)); > else > return false; > } > diff --git a/sql/sql_update.cc b/sql/sql_update.cc > index 38638d3aa1d..4ae7e33b4e3 100644 > --- a/sql/sql_update.cc > +++ b/sql/sql_update.cc > @@ -2205,10 +2195,41 @@ multi_update::initialize_tables(JOIN *join) > DBUG_RETURN(1); > tmp_tables[cnt]->file->extra(HA_EXTRA_WRITE_CACHE); > } > + join->tmp_table_keep_current_rowid= TRUE; > DBUG_RETURN(0); > } > (Follwing explanations on Slack) Please add a comment there, saying that Here we walk through the aggegation temptable to find where rowids are stored. And then for each of the multi-update tables, we get them to copy the data from the rowid field in the aggregation temptable. > + > +int multi_update::prepare2(JOIN *join) > +{ > + if (!join->need_tmp || !join->tmp_table_keep_current_rowid) > + return 0; > + > + // there cannot be many tmp tables in multi-update > + JOIN_TAB *tmptab= join->join_tab + join->exec_join_tab_cnt(); > + > + for (Item **it= tmptab->tmp_table_param->items_to_copy; *it ; it++) > + { > + TABLE *tbl= (*it)->rowid_table(); > + if (!tbl) > + continue; > + for (uint i= 0; i < table_count; i++) > + { > + for (Item **it2= tmp_table_param[i].items_to_copy; *it2; it2++) > + { > + if ((*it2)->rowid_table() != tbl) > + continue; > + *it2= new (thd->mem_root) Item_field(thd, (*it)->get_tmp_table_field()); > + if (!*it2) > + return 1; > + } > + } > + } > + return 0; > +} > + > + > multi_update::~multi_update() > { > TABLE_LIST *table; BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 5

[Maria-developers] FOR UPDATE behavior change in 10.3-MDEV-11953
by Alexander Barkov 12 Apr '18

12 Apr '18

Hi Sanja, and Igor, (resending with Igor on CC) I noticed a FOR UPDATE behavior change in 10.3-MDEV-11953 In 10.3 I run this script in a client session: CREATE OR REPLACE TABLE t1 (a INT NOT NULL PRIMARY KEY); CREATE OR REPLACE TABLE t2 (a INT NOT NULL PRIMARY KEY); INSERT INTO t1 VALUES (1); INSERT INTO t2 VALUES (2); BEGIN; SELECT * FROM t1 UNION SELECT * FROM t2 FOR UPDATE; Notice no COMMIT yet! It returns this result: +---+ | a | +---+ | 1 | | 2 | +---+ Now I open a new console, start a new client session and run this script: BEGIN; SELECT * FROM t2 FOR UPDATE; The second session gets locked, as expected. Now I return to the first console and run "COMMIT;". The second console gets unlocked and returns +---+ | a | +---+ | 2 | +---+ Now if I do the same in 10.3-MDEV-11953, the second session does not get locked, it returns the result immediately, even before I typed "COMMIT;" in the first session. Note, if in 10.3-MDEV-11953 I start a transaction with a simpler query (without UNION) in the first session: BEGIN; SELECT * FROM t2 FOR UPDATE; and run the same script in the second session BEGIN; SELECT * FROM t2 FOR UPDATE; then the second session gets locked as expected. Is this behavior change expected? Thanks!

2 1

Re: [Maria-developers] FOR UPDATE behavior change in 10.3-MDEV-11953
by Alexander Barkov 12 Apr '18

12 Apr '18

Hi Igor, Please do "reply all" when replying. On 04/12/2018 01:28 AM, Igor Babaev wrote: > Alexander, > > If you have the same behaviour you have to use > > SELECT * FROM t1 UNION (SELECT * FROM t2 FOR UPDATE). Thanks. This worked fine for me. > > Otherwise it's considered as > > (SELECT * FROM t1 UNION SELECT * FROM t2 FOR UPDATE). What does this syntax mean 10.3-MDEV-11953? Which records should be locked? From t1, from t2, or from both? It seems that it locks nothing. If so, shouldn't this be disallowed? This query (without parentheses) also locks nothing: SELECT * FROM t1 UNION SELECT * FROM t2 FOR UPDATE; > > MySQL manual says that 'FOR UPDATE' must follow ORDER BY, > > but it does not tell you how to interpret FOR UPDATE in unions. The old behavior was to interpret UNION parts separately. This locked only t2 in 10.3: SELECT * FROM t1 UNION SELECT * FROM t2 FOR UPDATE; In 10.3-MDEV-11953 it locks nothing. Upgrade looks dangerous. Can we do this way: 1. In 10.4: disallow FOR UPDATE applied to the entire UNION. 2. In 10.3: Add a warning which tells that this feature is deprecated and suggests to use parentheses around union parts when a non-parenthesized union term is used with FOR UPDATE ? > > Anyway you can't use anymore: > SELECT c FROM t1 ORDER BY a > UNION > SELECT c FROM t2 ORDER BY b > ORDER BY c. > > You have to put it so: > (SELECT c FROM t1 ORDER BY a) > UNION > (SELECT c FROM t2 ORDER BY b) > ORDER BY c. > > (see the standard). I like this change. > > It means that the ORDER BY clause followed a union relates to the union. > The same is true for 'FOR UPDATE' because it follows optional ORDER BY/ > LIMIT clauses. > > > Regards, > Igor. > > > On 04/11/2018 09:10 AM, Alexander Barkov wrote: >> Hi Sanja, and Igor, >> >> >> (resending with Igor on CC) >> >> >> I noticed a FOR UPDATE behavior change in 10.3-MDEV-11953 >> >> In 10.3 I run this script in a client session: >> >> CREATE OR REPLACE TABLE t1 (a INT NOT NULL PRIMARY KEY); >> CREATE OR REPLACE TABLE t2 (a INT NOT NULL PRIMARY KEY); >> INSERT INTO t1 VALUES (1); >> INSERT INTO t2 VALUES (2); >> BEGIN; >> SELECT * FROM t1 UNION SELECT * FROM t2 FOR UPDATE; >> >> Notice no COMMIT yet! It returns this result: >> +---+ >> | a | >> +---+ >> | 1 | >> | 2 | >> +---+ >> >> Now I open a new console, start a new client session and run this script: >> >> BEGIN; >> SELECT * FROM t2 FOR UPDATE; >> >> The second session gets locked, as expected. >> >> Now I return to the first console and run "COMMIT;". >> The second console gets unlocked and returns >> +---+ >> | a | >> +---+ >> | 2 | >> +---+ >> >> >> Now if I do the same in 10.3-MDEV-11953, the second session does not get >> locked, it returns the result immediately, even before I typed "COMMIT;" >> in the first session. >> >> >> Note, if in 10.3-MDEV-11953 I start a transaction with a simpler query >> (without UNION) in the first session: >> >> BEGIN; >> SELECT * FROM t2 FOR UPDATE; >> >> and run the same script in the second session >> >> BEGIN; >> SELECT * FROM t2 FOR UPDATE; >> >> then the second session gets locked as expected. >> >> >> Is this behavior change expected? >> >> >> Thanks! >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~maria-developers >> Post to : maria-developers(a)lists.launchpad.net >> Unsubscribe : https://launchpad.net/~maria-developers >> More help : https://help.launchpad.net/ListHelp >>

2 3

[Maria-developers] Issue with setting up of MariaDB and solve issue MDEV-14896
by Aman Jain 11 Apr '18

11 Apr '18

Hello developers I am setting up the codebase for MariaDB on my system to understand the codebase and solve some issues. But I am facing a problem which I am not able to solve when I run "make" command. Error log: https://pastebin.com/u5fAhMHX OS: MacOS 10.13.3 Python version: 2.7.14 Please let me know how can I set up so that I can run and test the changes. Also, I want to solve issue MDEV-14896. Please connect me to the owner of the issue so that I can discuss the changes. ( https://jira.mariadb.org/browse/MDEV-14896 ) Thanks Aman Jain

3 5

[Maria-developers] 10.3-MDEV-11953
by Alexander Barkov 11 Apr '18

11 Apr '18

Hi Sanja and Igor, In 10.3-MDEV-11953 you're adding a number of main_select_push() / pop_select() around "expr" and other rules that contain "expr". How do you decide when push/pop is needed. Why, for example, LIMIT and ORDER clause don't have their own push/pop. They do create some expressions (Items). What is the rule? Thanks.

1 0

[Maria-developers] FOR UPDATE behavior change in 10.3-MDEV-11953
by Alexander Barkov 11 Apr '18

11 Apr '18

Hi Sanja, I noticed a FOR UPDATE behavior change in 10.3-MDEV-11953 In 10.3 I run this script in a client session: CREATE OR REPLACE TABLE t1 (a INT NOT NULL PRIMARY KEY); CREATE OR REPLACE TABLE t2 (a INT NOT NULL PRIMARY KEY); INSERT INTO t1 VALUES (1); INSERT INTO t2 VALUES (2); BEGIN; SELECT * FROM t1 UNION SELECT * FROM t2 FOR UPDATE; Notice no COMMIT yet! It returns this result: +---+ | a | +---+ | 1 | | 2 | +---+ Now I open a new console, start a new client session and run this script: BEGIN; SELECT * FROM t2 FOR UPDATE; The second session gets locked, as expected. Now I return to the first console and run "COMMIT;". The second console gets unlocked and returns +---+ | a | +---+ | 2 | +---+ Now if I do the same in 10.3-MDEV-11953, the second session does not get locked, it returns the result immediately, even before I typed "COMMIT;" in the first session. Note, if in 10.3-MDEV-11953 I start a transaction with a simpler query (without UNION) in the first session: BEGIN; SELECT * FROM t2 FOR UPDATE; and run the same script in the second session BEGIN; SELECT * FROM t2 FOR UPDATE; then the second session gets locked as expected. Is this behavior change expected? Thanks!

1 0

Re: [Maria-developers] 57673bc: MDEV-14024 PCRE2
by Sergei Golubchik 11 Apr '18

11 Apr '18

Hi, Alexey! On Apr 03, Alexey Botchkov wrote: > revision-id: 57673bcfeecf51d1dd8f4907adc8ca11d84796d3 (mariadb-10.3.5-76-g57673bc) > parent(s): d614d4b2e61552a5b74259f91b3e14b23707743f > committer: Alexey Botchkov > timestamp: 2018-04-03 02:59:51 +0400 > message: > > MDEV-14024 PCRE2. > > server ocde switched to the PCRE2 features. ^^^ s/ocde/code/ > diff --git a/cmake/pcre.cmake b/cmake/pcre.cmake > index 4c11392..271dd06 100644 > --- a/cmake/pcre.cmake > +++ b/cmake/pcre.cmake > @@ -5,24 +5,16 @@ SET(WITH_PCRE "auto" CACHE STRING > > + IF(NOT HAVE_PCRE2 OR WITH_PCRE STREQUAL "bundled") > IF (WITH_PCRE STREQUAL "system") > - MESSAGE(FATAL_ERROR "system pcre is not found or unusable") > + MESSAGE(FATAL_ERROR "system pcre2-8 is not found or unusable") better "pcre2-8 library" or simply "pcre2" > diff --git a/sql/item_cmpfunc.cc b/sql/item_cmpfunc.cc > index 89aa307..08aa293 100644 > --- a/sql/item_cmpfunc.cc > +++ b/sql/item_cmpfunc.cc > @@ -5481,15 +5481,6 @@ int Regexp_processor_pcre::default_regex_flags() > return default_regex_flags_pcre(current_thd); > } > > -void Regexp_processor_pcre::set_recursion_limit(THD *thd) > -{ > - long stack_used; > - DBUG_ASSERT(thd == current_thd); > - stack_used= available_stack_size(thd->thread_stack, &stack_used); > - m_pcre_extra.match_limit_recursion= > - (ulong)((my_thread_stack_size - STACK_MIN_SIZE - stack_used)/my_pcre_frame_size); > -} > - > > /** > Convert string to lib_charset, if needed. > @@ -5537,19 +5528,32 @@ bool Regexp_processor_pcre::compile(String *pattern, bool send_error) > if (!(pattern= convert_if_needed(pattern, &pattern_converter))) > return true; > > - m_pcre= pcre_compile(pattern->c_ptr_safe(), m_library_flags, > - &pcreErrorStr, &pcreErrorOffset, NULL); > + m_pcre= pcre2_compile((PCRE2_SPTR8) pattern->ptr(), pattern->length(), > + m_library_flags, > + &pcreErrorNumber, &pcreErrorOffset, NULL); > > if (m_pcre == NULL) > { > if (send_error) > { > char buff[MAX_FIELD_WIDTH]; > - my_snprintf(buff, sizeof(buff), "%s at offset %d", pcreErrorStr, pcreErrorOffset); > + int lmsg= pcre2_get_error_message(pcreErrorNumber, > + (PCRE2_UCHAR8 *)buff, sizeof(buff)); > + if (lmsg >= 0) > + my_snprintf(buff+lmsg, sizeof(buff)-lmsg, > + " at offset %d", pcreErrorOffset); if lmsg < 0, does it guarantee that the buffer is 0-terminated? > my_error(ER_REGEXP_ERROR, MYF(0), buff); > } > return true; > } > + > + m_pcre_match_data= pcre2_match_data_create_from_pattern(m_pcre, NULL); > + if (m_pcre_match_data == NULL) > + { > + my_error(ER_OUT_OF_RESOURCES, MYF(0)); > + return true; > + } > + > return false; > } > > @@ -5570,124 +5574,43 @@ bool Regexp_processor_pcre::compile(Item *item, bool send_error) > */ > void Regexp_processor_pcre::pcre_exec_warn(int rc) const > { ... > - push_warning_printf(thd, Sql_condition::WARN_LEVEL_WARN, > - ER_REGEXP_ERROR, ER_THD(thd, ER_REGEXP_ERROR), errmsg); > + int errlen= pcre2_get_error_message(rc, buf, sizeof(buf)); > + if (errlen >= 0) > + push_warning_printf(thd, Sql_condition::WARN_LEVEL_WARN, > + ER_REGEXP_ERROR, ER_THD(thd, ER_REGEXP_ERROR), buf); perhaps, issue some generic message if pcre2_get_error_message fails? > } > @@ -5697,14 +5620,12 @@ bool Regexp_processor_pcre::exec(String *str, int offset, > { > if (!(str= convert_if_needed(str, &subject_converter))) > return true; > - m_pcre_exec_rc= pcre_exec_with_warn(m_pcre, &m_pcre_extra, > - str->c_ptr_safe(), str->length(), > - offset, 0, > - m_SubStrVec, array_elements(m_SubStrVec)); > + m_pcre_exec_rc= pcre_exec_with_warn(m_pcre, m_pcre_match_data, > + str->ptr(), str->length(), offset, 0); > if (m_pcre_exec_rc > 0) > { > uint i; > - for (i= 0; i < n_result_offsets_to_convert; i++) > + for (i= 0; i < n_result_offsets_to_convert && i < m_pcre_exec_rc-1; i++) hmm, what does that mean? that both n_result_offsets_to_convert < m_pcre_exec_rc-1 and m_pcre_exec_rc-1 < n_result_offsets_to_convert are possible? > { > /* > Convert byte offset into character offset. > diff --git a/sql/item_cmpfunc.h b/sql/item_cmpfunc.h > index 3d11a22..d3f52ed 100644 > --- a/sql/item_cmpfunc.h > +++ b/sql/item_cmpfunc.h > @@ -25,7 +25,8 @@ > > #include "item_func.h" /* Item_int_func, Item_bool_func */ > #define PCRE_STATIC 1 /* Important on Windows */ > -#include "pcre.h" /* pcre header file */ > +#define PCRE2_CODE_UNIT_WIDTH 8 you sure, you want it here and not, say, in one universally-included headers like my_config.h? You don't define it in other places now, so they include different function names and macros. > +#include "pcre2.h" /* pcre header file */ > #include "item.h" > > extern Item_result item_cmp_type(Item_result a,Item_result b); > diff --git a/sql/mysqld.cc b/sql/mysqld.cc > index fe2b9c8..dcf0996 100644 > --- a/sql/mysqld.cc > +++ b/sql/mysqld.cc > @@ -111,7 +111,7 @@ > #include "sp_rcontext.h" > #include "sp_cache.h" > #include "sql_reload.h" // reload_acl_and_cache > -#include "pcre.h" > +#include "pcre2.h" do you still need to include pcre header here? > > #ifdef HAVE_POLL_H > #include <poll.h> > diff --git a/storage/mroonga/CMakeLists.txt b/storage/mroonga/CMakeLists.txt > index 5d8e8c1..57d12a1 100644 > --- a/storage/mroonga/CMakeLists.txt > +++ b/storage/mroonga/CMakeLists.txt > @@ -189,8 +189,8 @@ else() > set(MYSQL_VARIANT "MySQL") > endif() > > -if(EXISTS "${MYSQL_SOURCE_DIR}/pcre") > - set(MYSQL_REGEX_INCLUDE_DIR "${MYSQL_SOURCE_DIR}/pcre") > +if(EXISTS "${MYSQL_SOURCE_DIR}/pcre2") > + set(MYSQL_REGEX_INCLUDE_DIR "${MYSQL_SOURCE_DIR}/pcre2/src") eh, is that enough? there were a lot more changes in the server, than just correcting the path. > else() > set(MYSQL_REGEX_INCLUDE_DIR "${MYSQL_SOURCE_DIR}/regex") > endif() Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] FYI: 10.3 master branch head builds OK Launchpad all architectures
by Otto Kekäläinen 11 Apr '18

11 Apr '18

Hello! Just for the record, I've done some small tweaks to 10.3 so that it now builds perfectly and passes build tests on all Launchpad architectures that I have access to. https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.3/+build s?build_text=&build_state=all Let's hope it stays like this for the rest of the current 10.3 cycle and will not regress by before it is announced GA.. On buildbot the Debian sid and Ubuntu Bionic builders pass now. There are however some sporadic failures left. http://buildbot.askmonty.org/buildbot/grid?branch=10.3&category=main&ca tegory=experimental On Travis everything else passes apart from one test, which has been consistently failing for some time. Everything was green in January when I wrote the protected branches blog post, so this one is a consistently failing regression. https://travis-ci.org/MariaDB/server/builds/362466962 - Otto

2 5

[Maria-developers] Temporary table bug
by Badrul Chowdhury 09 Apr '18

09 Apr '18

Hi, Is anyone actively working on https://jira.mariadb.org/browse/MDEV-12459? If not, I would like to take a look. -- Thanks, Badrul

2 2