- developers - lists.mariadb.org

Re: [Maria-developers] 6cf25e5eb76: Session tracking info support in mysqltest
by Sergei Golubchik 09 Mar '18

09 Mar '18

Hi, Oleksandr! On Mar 09, Oleksandr Byelkin wrote: > revision-id: 6cf25e5eb76923550173a0059036d80c80a053d6 (mariadb-10.2.13-31-g6cf25e5eb76) > parent(s): f2b91c878cf4ec53c292caba7f5907d1ef724de4 > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2018-03-09 14:27:13 +0100 > message: > > Session tracking info support in mysqltest Add a test case for it. Don't forget to test whether ONCE modifier works. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] f2b91c878cf: Reset connection support in mysqltest
by Sergei Golubchik 09 Mar '18

09 Mar '18

Hi, Oleksandr! On Mar 09, Oleksandr Byelkin wrote: > revision-id: f2b91c878cf4ec53c292caba7f5907d1ef724de4 (mariadb-10.2.13-30-gf2b91c878cf) > parent(s): 8f98835bb86550a68a6c412d8417cc169dfdc206 > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2018-03-09 14:26:10 +0100 > message: > > Reset connection support in mysqltest You add a feature - add a test case for it too. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] MariaDB 5.5, Jemalloc, TokuDB, RHEL
by Michal Schorm 08 Mar '18

08 Mar '18

Hello, so far we packed MariaDB 5.5 for RHEL 7 without TokuDB and without Jemalloc. Recently, a customer asked about the availability of TokuDB, so I'm doing a research, if its possible to pack it without any issues for the users updating. I have a several questions: 1) Is Jemmaloc used elsewhere from TokuDB ? 2) If yes, what all would be affected? Could any issues arise during update from build without Jemalloc to build with it? Any expected performance changes? 3) Would be the use of the bundled Jemalloc (on of the) best option(s)? 4) Anything else that I missed? -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat

2 1

[Maria-developers] Introduction as GSoC 2018 aspirant
by Arshdeep Singh Sachdeva 05 Mar '18

05 Mar '18

Dear MariaDB Developers, I am Arshdeep Singh Sachdeva, currently studying BTech ( C.S.E. ) from Punjab Engineering College, Chandigarh, India. I am interested in contibuting to MariaDB and participating in GSoC 2018 under your guidance. I am proficient in C++, python, linux, mysql. I have already used MariaDB in my projects in college. Also I am presently going through documentation and tutorials. Thanks.

1 0

[Maria-developers] Introduction as a GSoC aspirant
by Aman Jain 05 Mar '18

05 Mar '18

Hello developers and mentors I am Aman and I am interested in contributing to MariaDB as a GSoC'18 aspirant. I am familiar with C++, Web development, SQL, MongoDB and shell scripting and I have set up the MariaDB server. Please suggest me where I can find the source code so that I can get a better understanding of the project ideas and solve some issues to get started. Thanks Aman Jain

2 1

Re: [Maria-developers] [Commit] MDEV-12746 out-of-order retry
by Kristian Nielsen 17 Feb '18

17 Feb '18

andrei.elkin(a)pp.inet.fi writes: > commit 3cebb54e6387a7eace1757c82ed0efd6e11590b9 > Author: Andrei Elkin <andrei.elkin(a)mariadb.com> > Date: Fri Feb 9 15:00:23 2018 +0200 > > MDEV-12746 rpl.rpl_parallel_optimistic_nobinlog fails committing > out of order at retry > > The 2nd issue was out of order commit by transactions that > are ordered after an erroring out transaction. The latter was possible > in the test thanks to the above retry failure. > Out-of-order committing was done despite the slave was stopping. Let me see if I understand this correctly: Normally, a transaction in optimistic parallel replication cannot commit out of order because it either waits for the prior transaction to commit first, or, if the prior transaction has stopped with an error earlier, then the following transaction will not even start. But in this case, during retry, there was missing the check that the prior transaction stopped with an error. Therefore, the following transaction's wait_for_prior_commit() does nothing, and it wrongly goes ahead and runs and even commits, even though an earlier transaction failed and replication is stopping. Correct? That's a nice catch of a subtle, but potentially serious bug. I wonder how this is possible though. As I recall, when a transaction fails, this failure is marked in the wait_for_prior_commit data structures. So the retrying transaction should have gotten an error in wait_for_prior_commit() and aborted the retries. So why does this not happen in this case? > The test failures were of two sorts. One is that the number of potential > temporary errors actually exceeds the default value of the slave retry > option. > Increased @@global.slave_transaction_retries fixes that part. Hm, this shouldn't be needed, I think. The retry waits for all prior transactions to commit first, so after the first retry no further retries should be caused by other parallel replication workers. So I would expect this problem to be a side-effect of the other, real issue, and this increase should not be needed (and might hide another problem later, if left in). > diff --git a/sql/rpl_parallel.cc b/sql/rpl_parallel.cc > index 34f9113f7fe..9f1d23a1161 100644 > --- a/sql/rpl_parallel.cc > +++ b/sql/rpl_parallel.cc > @@ -745,7 +761,25 @@ retry_event_group(rpl_group_info *rgi, rpl_parallel_thread *rpt, > for (;;) > { > mysql_mutex_lock(&entry->LOCK_parallel_entry); > - register_wait_for_prior_event_group_commit(rgi, entry); > + if (entry->stop_on_error_sub_id == (uint64) ULONGLONG_MAX || > +#ifndef DBUG_OFF > + (DBUG_EVALUATE_IF("simulate_mdev_12746", 1, 0)) || > +#endif > + rgi->gtid_sub_id < entry->stop_on_error_sub_id) > + { > + register_wait_for_prior_event_group_commit(rgi, entry); > + } > + else > + { > + /* > + An earlier transaction by another worker may have not had not > + have the current one in subsequent committers list and thus > + the actual induced error status could not have been sumbitted. > + So it should be set by ourselves now. > + */ This comment is hard to understand - what do you mean here? > + if (!rgi->worker_error) > + rgi->worker_error= 1; > + } I would have expected an abort (goto err) here (or well just below, after unlocking the mutex). Is this not needed, and if so, why not? > @@ -716,12 +724,20 @@ retry_event_group(rpl_group_info *rgi, rpl_parallel_thread *rpt, > unregistering (and later re-registering) the wait. > */ > if(thd->wait_for_commit_ptr) > - thd->wait_for_commit_ptr->unregister_wait_for_prior_commit(); > + thd->wait_for_commit_ptr->unregister_wait_for_prior_commit(); Indentation? - Kristian.

2 5

[Maria-developers] Developers Unconference in New York
by Ian Gilfillan 16 Feb '18

16 Feb '18

A final reminder about the Developers Unconference happening in New York on Sat 24 and Sun 25 February, just before M|18. https://mariadb.org/2018-mariadb-developers-unconference/ Please sign up on the Meetup page if you are going to be attending: https://www.meetup.com/MariaDB-Developers/events/244375856/ Hope to see you there!

1 0

[Maria-developers] Google Summer of Code 2018 - MariaDB Foundation accepted
by Colin Charles 14 Feb '18

14 Feb '18

Hi, I just noticed this piece of good news — MariaDB Foundation is accepted to participate in the Google Summer of Code 2018 again — https://summerofcode.withgoogle.com/ There is an already healthy list of ideas: https://mariadb.com/kb/en/library/google-summer-of-code-2018/ Many already have mentors from MariaDB Corporation or MariaDB Foundation. Some are looking for mentors. Happy coding this summer! cheers, -colin -- Colin Charles, http://bytebot.net/blog/ twitter: @bytebot | skype: colincharles "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi

1 0

Re: [Maria-developers] [Commits] f4f32ab71d5: MDEV-9744: session optimizer_use_condition_selectivity=5 causing SQL Error (1918):
by Sergey Petrunia 13 Feb '18

13 Feb '18

Hi Varun, On Sat, Feb 03, 2018 at 06:37:21PM +0530, Varun wrote: > revision-id: f4f32ab71d5c96fbec87f8b6a5c057af2bc2398b (mariadb-10.2.5-413-gf4f32ab71d5) > parent(s): 9390ff53fc39e34976cf051ce33649f9316bb8e6 > author: Varun Gupta > committer: Varun Gupta > timestamp: 2018-02-03 18:24:49 +0530 > message: > > MDEV-9744: session optimizer_use_condition_selectivity=5 causing SQL Error (1918): > Encountered illegal value '' when converting to DECIMAL > > The issue was that EITS data was allocated but then not read for some reason (one being to avoid a deadlock), > then the optimizer was using these bzero'ed buffers as EITS statistics. > This should not be allowed, we should use statistcs for a table only when we have successfully loaded/read > the stats from the statistical tables. > > --- > mysql-test/r/statistics.result | 16 ++++++++++++++++ > mysql-test/t/statistics.test | 19 +++++++++++++++++++ > sql/sql_statistics.cc | 23 ++++++++++++++++------- > 3 files changed, 51 insertions(+), 7 deletions(-) > > diff --git a/mysql-test/r/statistics.result b/mysql-test/r/statistics.result > index ffaaf09acc8..1486a8ab5e6 100644 > --- a/mysql-test/r/statistics.result > +++ b/mysql-test/r/statistics.result > @@ -1716,5 +1716,21 @@ b > 0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.004,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.004,0.000,0.000,0.004,0.000,0.000,0.000,0.004,0.000,0.000,0.000,0.004,0.000,0.000,0.000,0.004,0.000,0.004,0.000,0.000,0.004,0.000,0.004,0.000,0.004,0.000,0.004,0.004,0.004,0.000,0.004,0.000,0.004,0.004,0.004,0.004,0.004,0.000,0.004,0.004,0.004,0.004,0.004,0.004,0.008,0.004,0.008,0.008,0.008,0.008,0.020,0.004,0.016,0.020,0.016,0.016,0.051,0.031,0.027,0.031,0.043,0.047,0.043,0.043,0.055,0.051,0.071,0.043,0.043,0.043,0.020,0.024,0.024,0.020,0.016,0.016,0.008,0.008,0.012,0.000 > DROP TABLE t1; > # > +# MDEB-9744: session optimizer_use_condition_selectivity=5 causing SQL Error (1918): Please change to "MDEV" > +# Encountered illegal value '' when converting to DECIMAL > +# > +set @save_optimizer_use_condition_selectivity= @@optimizer_use_condition_selectivity; > +set optimizer_use_condition_selectivity=3, use_stat_tables=preferably; > +create table a (id int(10),cost decimal(9,2)) engine=innodb; > +ANALYZE TABLE a PERSISTENT FOR ALL; > +Table Op Msg_type Msg_text > +test.a analyze status Engine-independent statistics collected > +test.a analyze status OK > +create temporary table b (id int); > +insert into b (id) select id from a where cost > 0; > +drop table a,b; Please follow the convention and use table names t1,t2,... Ok to push after this is addressed. BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Commits] MDEV-15167 Server crashes in in bitmap_bits_set upon REPAIR PARTITION ...
by Sergei Golubchik 10 Feb '18

10 Feb '18

Hi, Sachin! On Feb 09, Sachin Setiya wrote: > commit 3e49ebcacf9022931f0dfefcb44c13973128f8c4 > Author: Sachin Setiya <sachinsetia1001(a)gmail.com> > Date: Fri Feb 9 17:44:04 2018 +0530 > > MDEV-15167 Server crashes in in bitmap_bits_set upon REPAIR PARTITION > ... > > diff --git a/sql/sql_partition.cc b/sql/sql_partition.cc > index a4d9406..3d53056 100644 > --- a/sql/sql_partition.cc > +++ b/sql/sql_partition.cc > @@ -4583,6 +4583,11 @@ uint prep_alter_part_table(THD *thd, TABLE *table, > Alter_info *alter_info, > Alter_info::ALTER_TABLE_REORG | > Alter_info::ALTER_REBUILD_PARTITION)) > { > + /* > + You can't add column when we are doing alter related to partition > + */ > + DBUG_EXECUTE_IF("test_pseudo_invisible",{DBUG_ASSERT(0);}); > + DBUG_EXECUTE_IF("test_completely_invisible",{DBUG_ASSERT(0);}); May be return error? Like with P_S? DBUG_EXECUTE_IF("test_pseudo_invisible", {DBUG_RETURN(1)}); but test it, may be you'll need my_error too, like DBUG_EXECUTE_IF("test_pseudo_invisible", { my_error(ER_INTERNAL_ERROR, MYF(0), "Don't to it with test_pseudo_invisible"); DBUG_RETURN(1) }); Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0