- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] 68b5057: always use my_b_pread() instead of mysql_file_pread()
by Sergey Vojtovich 02 Jun '15

02 Jun '15

Hi Sergei, ok to push. Regards, Sergey On Tue, May 26, 2015 at 03:38:11PM +0200, serg(a)mariadb.org wrote: > revision-id: 68b5057695165b88db38d5090f45ebe3a5149995 > parent(s): ab7640f4d30f5a160d3a1c77efe9d2c459a3bda6 > committer: Sergei Golubchik > branch nick: maria > timestamp: 2015-05-26 15:28:24 +0200 > message: > > always use my_b_pread() instead of mysql_file_pread() > > when working with IO_CACHE's, don't access IO_CACHE::file directly

1 0

[Maria-developers] MDEV-7502 Automatic provisioning of slave
by Martin Kaluznik 02 Jun '15

02 Jun '15

Provisioning has to be triggered by a command from slave, so my implementation started there. After performing initial checks, command handler starts IO and SQL threads, like during regular replication. I was trying to write separate code for provisioning IO thread. Main benefit would be clean code to start with – no backward compatibility / bug workaround code – old master will not be able to provide provisioning functionality anyway. On the other hand there would be too much duplicate code, and having to do future changes on two different places is not acceptable. I have decided to use regular replication IO thread as Kristian Nielsen suggested before and add special handling where necessary. Now when the IO thread requests binlog dump from master, it sends packet with following structure master position | binlog flags | server id | log name Master needs to receive information, that slaves IO thread is expecting provisioning data along with current binlog. I have created new BINLOG_PROVISIONING_MODE flag, but I believe that the name is incorrect and it doesn’t belong to binlog flags field. My question is, what is better for compatibility, change binlog flags to any flags and use it for sending information about provisioning request to master (as in current implementation) or add another byte to packet after log name containing provisioning mode flag and possibly more flags later. My current implementation progress can be seen at https://github.com/f4rnham/server/commits/MDEV-7502 diff of all commits at once https://github.com/MariaDB/server/compare/10.1...f4rnham:MDEV-7502 There is one more decision I am not sure about. What should result of provisioning on non-empty slave be? For example, slave contains table with same name in same database as master, but with different columns. Should slave detect already existing tables and fail with error, or silently drop everything what could cause conflicts (add optional FORCE part of provisioning start command?). Which one from these solutions should be default? Or maybe there is third one and better. Thanks for comments, Martin

2 1

[Maria-developers] [GSoC] MXS-2: Week 1
by sriram patil 01 Jun '15

01 Jun '15

Hi All, Please find links to my first blog posts of this GSoC season below. MaxScale Installation and Configuration <http://srirampatil.tumblr.com/post/120346691880/maxscale-installation-and-c…> MXS-2: Week 1 <http://srirampatil.tumblr.com/post/120349951405/mxs-2-week-1> Feel fre to point out mistakes, if any. Also, suggestions ans/or reviews are welcome! Thanks, Sriram

1 0

Re: [Maria-developers] [Commits] 52c3687: MDEV-8241: Debug build on Windows is broken: error LNK2019: unresolved external symbol pthread_detach referenced in function ma_checkpoint_init
by Sergei Golubchik 29 May '15

29 May '15

Hi, Sanja! On May 28, sanja(a)mariadb.com wrote: > revision-id: 52c36874e251c3ac5ff0f925c8133074166d481d > parent(s): 979c5049ef6fdd55c29fa5170a96c62d2a8a6823 > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-05-28 07:59:57 +0200 > message: > > MDEV-8241: Debug build on Windows is broken: error LNK2019: unresolved external symbol pthread_detach referenced in function ma_checkpoint_init > > pthread_detach() replaced with pthread_detach_this_thread() > > pthread_detach_this_thread() definition fixed > > diff --git a/storage/maria/ma_checkpoint.c b/storage/maria/ma_checkpoint.c > index 2268ca6..36b729e 100644 > --- a/storage/maria/ma_checkpoint.c > +++ b/storage/maria/ma_checkpoint.c > @@ -340,7 +340,6 @@ int ma_checkpoint_init(ulong interval) > { > /* thread lives, will have to be killed */ > checkpoint_control.status= THREAD_RUNNING; > - pthread_detach(th); > } > } > DBUG_RETURN(res); > @@ -574,6 +573,8 @@ pthread_handler_t ma_checkpoint_background(void *arg) > sleeps= 1; > pages_to_flush_before_next_checkpoint= 0; > > + pthread_detach_this_thread(); > + > for(;;) /* iterations of checkpoints and dirty page flushing */ > { How does that help? What was wrong with pthread_detach()? Regards, Sergei

2 1

Re: [Maria-developers] [Commits] 2b17bfc: MDEV-7484: Log Time not consistent with InnoDB errors nor with MySQL error log time format
by Sergei Golubchik 29 May '15

29 May '15

Hi, Jan! On May 22, Jan Lindström wrote: > revision-id: 2b17bfc6e14283aefeff87d959f3ecfc48af5c2c > parent(s): 8635c4b4e66712558330d9534491af0c9025e4dc > committer: Jan Lindström > branch nick: 10.1-encrypt > timestamp: 2015-05-22 08:24:59 +0300 > message: > > MDEV-7484: Log Time not consistent with InnoDB errors nor with MySQL error log time format Ok to push Regards, Sergei

1 0

[Maria-developers] Please review: MDEV-8222 "string_field LIKE int_const" returns a wrong result in case of UCS2
by Alexander Barkov 29 May '15

29 May '15

Hi Sergey, please review my patch for MDEV-8222. It also moves Arg_compatator from Item_bool_func2 to Item_bool_rowready_func2. Thanks.

1 0

Re: [Maria-developers] [Commits] 7819ddb: MDEV-8192 - THD::set_command() takes 0.05% in OLTP RO
by Sergei Golubchik 29 May '15

29 May '15

Hi, Sergey! On May 20, svoj(a)mariadb.org wrote: > revision-id: 7819ddb99be5dff26c8a2109ba70a54289a950ad > parent(s): fcb48ee418959ea2c05d528266bb2dcad5bce46b > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-05-20 16:55:20 +0400 > message: > > MDEV-8192 - THD::set_command() takes 0.05% in OLTP RO > > Moved THD::set_command() definition to sql_class.h so that it can be inlined. ok > Call PSI_server::set_thread_command() conditionally: it is cheaper than calling > dummy function when PFS is off (though it adds some overhead when PFS is on). I'm not sure about it. P_S will be used more and more over time, let's not intentionally penalize it. Regards, Sergei

2 2

Re: [Maria-developers] [Commits] 6efaf34: MDEV-7011: MAX_STATEMENT_TIME has no effect in a procedure after a previous successful statement
by Sergei Golubchik 29 May '15

29 May '15

Hi, Sanja! On May 21, sanja(a)mariadb.com wrote: > revision-id: 6efaf349adec30115bdb94b9a9927f7c5103ed99 > parent(s): 3e55ef26d49a900782d2c2bb2c03470faed6ec9d > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-05-21 16:31:24 +0200 > message: > > MDEV-7011: MAX_STATEMENT_TIME has no effect in a procedure after a previous successful statement > > Do not reset timer inside stored procedures and functions. > > diff --git a/sql/sql_class.h b/sql/sql_class.h > index ca532ae..ebb76df 100644 > --- a/sql/sql_class.h > +++ b/sql/sql_class.h > @@ -3966,6 +3966,8 @@ class THD :public Statement, > void reset_query_timer() > { > #ifndef EMBEDDED_LIBRARY > + if (spcont || in_sub_stmt) > + return; > if (!query_timer.expired) > thr_timer_end(&query_timer); > #endif I'd expect reset_query_timer() to use the same condition that set_query_timer() does: void set_query_timer() { if (!variables.max_statement_time || spcont || in_sub_stmt || slave_thread || query_timer.expired == 0) return; thr_timer_settime(&query_timer, variables.max_statement_time); } So, I'd think that reset_query_timer() could look like void reset_query_timer() { if (spcont || in_sub_stmt || slave_thread) return; if (!query_timer.expired) thr_timer_end(&query_timer); } Regards, Sergei

2 1

[Maria-developers] [GSoC] And it begins
by sriram patil 29 May '15

29 May '15

Hi All, Today is the official day (at least in my timezone) to start working on the GSoC'15 projects. I am totally excited! I will be working on MaxScale, MXS-2, for next 3 months. I will be posting a blog link every Monday starting from next week which will give an idea about what I did in the week previous to that and the tasks lined up for that week. I hope you all follow my blog. It will be great to get some inputs from the community as well. Also, all the best to all the other students who will be working with MariaDB this summer. Thanks, Sriram

2 2

Re: [Maria-developers] 8928497: MDEV-7067: Server outputs Galera (WSREP) information, even if Galera is disabled
by Sergei Golubchik 29 May '15

29 May '15

Hi, Nirbhay! On May 09, Nirbhay Choubey wrote: > revision-id: 8928497acbe3e17a105897f405d5e5138d57a249 > parent(s): 3674c363a7e77e534c3e0d28659dc614c53fbcbc > committer: Nirbhay Choubey > branch nick: 10.1-wsrep > timestamp: 2015-05-09 16:11:59 -0400 > message: > > MDEV-7067: Server outputs Galera (WSREP) information, even if Galera is disabled > > * mysqld_safe: Since wsrep_on variable is mandatory in 10.1, skip wsrep > position recovery if its OFF. > * mysqld: Remove "-wsrep" from server version > * mysqld: Remove wsrep patch version from @@version_comment > * mysqld: Introduce @@wsrep_patch_version Looks ok, I just didn't like the wsrep.cmake change. See below. > diff --git a/cmake/wsrep.cmake b/cmake/wsrep.cmake > index c37cf74..305ab27 100644 > --- a/cmake/wsrep.cmake > +++ b/cmake/wsrep.cmake > @@ -28,29 +28,22 @@ OPTION(WITH_WSREP "WSREP replication API (to use, e.g. Galera Replication librar > # Set the patch version > SET(WSREP_PATCH_VERSION "10") > > -# MariaDB addition: Revision number of the last revision merged from > -# codership branch visible in @@version_comment. > -# Branch : codership-mysql/5.6 > -SET(WSREP_PATCH_REVNO "4144") # Should be updated on every merge. > - > -# MariaDB addition: Revision number of the last revision merged from > -# Branch : lp:maria/maria-10.0-galera > -SET(WSREP_PATCH_REVNO2 "3919") # Should be updated on every merge. > - > -# MariaDB: Obtain patch revision number: > -# Update WSREP_PATCH_REVNO if WSREP_REV environment variable is set. > -IF (DEFINED ENV{WSREP_REV}) > - SET(WSREP_PATCH_REVNO $ENV{WSREP_REV}) > -ENDIF() > > -SET(WSREP_INTERFACE_VERSION 25) > +# Obtain wsrep API version > +EXECUTE_PROCESS( > + COMMAND sh -c "grep WSREP_INTERFACE_VERSION ${MySQL_SOURCE_DIR}/wsrep/wsrep_api.h | cut -d '\"' -f 2" > + OUTPUT_VARIABLE WSREP_API_VERSION > + RESULT_VARIABLE RESULT > +) I don't like calling grep|cut from cmake files. If you want to extract the version from wsrep_api.h, use cmake commands, e.g. FILE(STRINGS "${MySQL_SOURCE_DIR}/wsrep/wsrep_api.h" WSREP_API_H LIMIT_COUNT 1 REGEX "WSREP_INTERFACE_VERSION") STRING(REGEX MATCH .... > +STRING(REGEX REPLACE "(\r?\n)+$" "" WSREP_API_VERSION "${WSREP_API_VERSION}") > > -SET(WSREP_VERSION > - "${WSREP_INTERFACE_VERSION}.${WSREP_PATCH_VERSION}.r${WSREP_PATCH_REVNO}") > +SET(WSREP_VERSION "${WSREP_API_VERSION}.${WSREP_PATCH_VERSION}" > + CACHE STRING "WSREP version") make it INTERNAL, not STRING > SET(WSREP_PROC_INFO ${WITH_WSREP}) > > IF(WITH_WSREP) > - SET(COMPILATION_COMMENT "${COMPILATION_COMMENT}, wsrep_${WSREP_VERSION}") > + SET(WSREP_PATCH_VERSION "wsrep_${WSREP_VERSION}") > ENDIF() > > diff --git a/mysql-test/suite/sys_vars/r/sysvars_wsrep.result b/mysql-test/suite/sys_vars/r/sysvars_wsrep.result > index 9c392b1..1763078 100644 > --- a/mysql-test/suite/sys_vars/r/sysvars_wsrep.result > +++ b/mysql-test/suite/sys_vars/r/sysvars_wsrep.result > @@ -365,6 +365,20 @@ NUMERIC_BLOCK_SIZE NULL > ENUM_VALUE_LIST TOI,RSU > READ_ONLY NO > COMMAND_LINE_ARGUMENT OPTIONAL > +VARIABLE_NAME WSREP_PATCH_VERSION > +SESSION_VALUE NULL > +GLOBAL_VALUE wsrep_25.10 > +GLOBAL_VALUE_ORIGIN COMPILE-TIME > +DEFAULT_VALUE NULL > +VARIABLE_SCOPE GLOBAL > +VARIABLE_TYPE VARCHAR > +VARIABLE_COMMENT wsrep patch version > +NUMERIC_MIN_VALUE NULL > +NUMERIC_MAX_VALUE NULL > +NUMERIC_BLOCK_SIZE NULL > +ENUM_VALUE_LIST NULL > +READ_ONLY YES > +COMMAND_LINE_ARGUMENT NULL > VARIABLE_NAME WSREP_PROVIDER > SESSION_VALUE NULL > GLOBAL_VALUE none > diff --git a/mysql-test/suite/sys_vars/r/wsrep_patch_version_basic.result b/mysql-test/suite/sys_vars/r/wsrep_patch_version_basic.result > new file mode 100644 > index 0000000..80f29e6 > --- /dev/null > +++ b/mysql-test/suite/sys_vars/r/wsrep_patch_version_basic.result I've actually stopped creating sys_var tests for every new variable (even though I was the one who introduced sys_vars.all_vars test in the first place :). With the new I_S.SYSTEM_VARIABLES table we have all variables listed there anyway, with all properties. So there's no need to copy these boilerplate tests over and over. > diff --git a/mysql-test/suite/wsrep/suite.pm b/mysql-test/suite/wsrep/suite.pm > index 02dff24..33744a6 100644 > --- a/mysql-test/suite/wsrep/suite.pm > +++ b/mysql-test/suite/wsrep/suite.pm > @@ -27,6 +27,7 @@ push @::global_suppressions, > qr(WSREP: Could not open saved state file for reading: ), > qr(WSREP: option --wsrep-casual-reads is deprecated), > qr(WSREP: --wsrep-casual-reads=ON takes precedence over --wsrep-sync-wait=0), > + qr|WSREP: access file$gvwstate.dat$ failed$No such file or directory$|, why? > ); > > diff --git a/sql/mysqld.cc b/sql/mysqld.cc > index 14d904b..49a639b 100644 > --- a/sql/mysqld.cc > +++ b/sql/mysqld.cc > @@ -1902,13 +1902,15 @@ static void __cdecl kill_server(int sig_ptr) > } > #endif > > - if (WSREP_ON) > + /* Stop wsrep threads in case they are running. */ > wsrep_stop_replication(NULL); Does this print any messages? Regards, Sergei

2 1