- developers - lists.mariadb.org

[Maria-developers] Value returned by my_getcputime
by Weldon Whipple 14 Aug '13

14 Aug '13

Hello! (This is my first post to this list; long-time follower, however.) I've been looking at the block comment at the top of the my_getcputime() function at the bottom of the file mysys/my_getsystime.c The block comment reads: Return cpu time in milliseconds * 10 I interpret milliseconds * 10 to mean centiseconds (seconds * 10 ^ -2) I'm pretty sure I've convinced myself that it REALLY returns: seconds * 10 ^ -7 I think it would be more accurate to have the block comment read: Return cpu time in microseconds / 10 Am I "up in the night"? (I think the code itself is fine, and the callers of the function all do it correctly. I was just initially confused when I looked at the comment then the code.) Thanks in advance! Weldon Whipple weldon(a)whipple.org (P.S. I think I like Maria's implementation of userstat_v2 better than the original by Google/Percona ...)

2 1

Re: [Maria-developers] Review of patch for MDEV-4820
by Kristian Nielsen 14 Aug '13

14 Aug '13

>> SHOW VARIABLES or SELECT @@GLOBAL.gtid_strict_mode will show the current >> value. But there is no way to check if it was enabled eg. two weeks ago, if >> that is what you are asking (the value is not stored in the binlog). > That is really pity. Is it really so useful to give the user opportunity to > switch gtid mode on-the-fly? That option sounds really expensive. Isn't > binlog event ordering lost - or it can't be trusted anymore? Binlog event order is never lost, strict mode or no strict mode. That is the whole point: even if the user messes up, MariaDB GTID is still able to correctly find the right position in the binlog to start at. There is nothing expensive about changing gtid strict mode, nor any loss of trust. Gtid strict mode is something to help the _user_. The GTID _code_ does not care, it works correctly whether strict mode is enabled or not. The only thing strict mode does is give an error for some uses that are considered undesirable by people like you and me. All non-error cases work exactly the same whether strict mode is enabled or not. It seems the more I try to explain, the more I confuse the issue :-( Maybe it is better if I just go fix the actual bugs ... - Kristian.

1 0

Re: [Maria-developers] Rev 3804: MDEV-4712 : Fix "shutdown" test
by Sergei Golubchik 13 Aug '13

13 Aug '13

Hi, Vladislav! On Jul 31, Vladislav Vaintroub wrote: > ------------------------------------------------------------ > revno: 3804 > revision-id: wlad(a)montyprogram.com-20130731130414-ukqxbb0kxpexjnzp > parent: svoj(a)mariadb.org-20130731110211-09p66bwf4jrmi03i > committer: Vladislav Vaintroub <wlad(a)montyprogram.com> > branch nick: 10.0-serg > timestamp: Wed 2013-07-31 15:04:14 +0200 > message: > MDEV-4712 : Fix "shutdown" test. > > There is a race condition during shutdown, that happens when "show status" runs during shutdown. > Functions show_slave_running(), show_slave_received_heartbeats(), show_heartbeat_period() would dereference NULL pointer master_info_index, after this variable is set to NULL in slave_end() during shutdown. > Fix introduces check for master_info_index == NULL in the affected functions. Was it related to the new shutdown command? Or it could be also observed without it by, say, running show status in a loop, while stopping the server with mysqladmin? Regards, Sergei

2 1

[Maria-developers] Lack of linkage from MariaDB JIRA to commits
by Jeremy Cole 13 Aug '13

13 Aug '13

All, I have noticed that the MariaDB JIRA tickets are rarely linked to any specific commit which purportedly fixes them. Is there any standard at the moment for what should be done (and then it isn't followed) or is there no standard (and perhaps it should be made)? I would really like a consistent way to get to view the commits into various branches related to each MDEV issue, in a consistent way. Regards, Jeremy

5 9

[Maria-developers] 10.x compatibility and separate namespace
by Honza Horak 13 Aug '13

13 Aug '13

Hi Guys, since 10.x won't be compatible with mysql in every aspect any more, I'm wondering if there happen to be any plans to move all compatibility left-overs (client binary names, client library name, daemon binary name, etc.). Are there any such ideas? I understand that we would lose the compatibility for any later (keeping original names was mentioned in [1] as a MUST for compatibility), but when keeping the original names, it could become tricky to say which tools are compatible and which not any more in mariadb 10+. How this information will be provided actually? How to get users informed properly, which tools are not compatible any more? And a bit another POV -- is the incompatibility in 10.x strictly limited to the server only (so client side will stay compatible for anytime later)? [1] https://lists.launchpad.net/maria-discuss/msg00658.html Regards, Honza

3 2

Re: [Maria-developers] Review of patch for MDEV-4820
by Kristian Nielsen 13 Aug '13

13 Aug '13

Vilho Raatikka <vilho.raatikka(a)skysql.com> writes: > What exactly does it require for the user to enable strict or 'relaxed' > (=disasterous imho) mode? Technically, one needs to SET GLOBAL gtid_strict_mode=1 with root privileges (config file option works as well of course). That's it. The practical issue is that old-style MariaDB/MySQL replication allows a number of "disasterous" uses. One example is a multi-master ring A->B->C->A, writing to all masters simultaneously. In such setup, it is fundamentally impossible to automatically eg. move a slave S from A->S to B->S - there is just not enough information about what events have been applied to S from A, B, and C. GTID introduces a way to configure this correctly (replication domains), but if we were to give an error by default then we would break upgrades from 5.5. So instead we provide gtid strict mode, so that once users understand what the "disasterous" uses are and how to avoid them, they can enable strict mode and get saner semantics. BTW, for the normal non-advanced user, I think silly stuff like running random manual transactions on slaves that get into the binlog is a far more common mistake. Gtid strict mode will cause errors on this, so it needs to be explictly enabled by users to not break/confuse upgrades. > Is it possible at any point in server's life cycle to check which mode it > is running? SHOW VARIABLES or SELECT @@GLOBAL.gtid_strict_mode will show the current value. But there is no way to check if it was enabled eg. two weeks ago, if that is what you are asking (the value is not stored in the binlog). > Can that setting be modified during runtime or only prior startup? It can be changed at any time, though I think you need to STOP SLAVE/START SLAVE to get the change to take effect on a slave. - Kristian.

1 1

[Maria-developers] RFC: Compile-time checking for unmatched DBUG_ENTER/LEAVE via unused variable
by Jeremy Cole 11 Aug '13

11 Aug '13

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: 1. Some instrumented functions are called only from non-instrumented functions. 2. Some instrumented functions are called only from non-returning functions, such as abort or die functions. 3. Some instrumented functions are called from functions who call my_end or my_thread_end (making cs unavailable) before returning. In any case please see the attached DRAFT patch for a full implementation of the idea. Note one bit of ugliness is that non-returning functions, after this patch, must be marked explicitly as DBUG_ENTER_NO_RETURN -- this actually is not really a bad thing, though in and of itself. Regards, Jeremy

4 4

Re: [Maria-developers] Rev 3671: MDEV-4652 Wrong result for CONCAT(GREATEST(TIME('00:00:01'), TIME('00:00:00')))
by Sergei Golubchik 11 Aug '13

11 Aug '13

Hi, Alexander! On Aug 07, Alexander Barkov wrote: > At lp:~maria-captains/maria/5.3 > > ------------------------------------------------------------ > revno: 3671 > revision-id: bar(a)mariadb.org-20130807093420-khdah292yerbor8y > parent: sergii(a)pisem.net-20130715163225-6ch6x34lsufode3d > committer: Alexander Barkov <bar(a)mariadb.org> > branch nick: 5.3.b4652 > timestamp: Wed 2013-08-07 13:34:20 +0400 > message: > MDEV-4652 Wrong result for CONCAT(GREATEST(TIME('00:00:01'),TIME('00:00:00'))) Ok to push. > === modified file 'sql/item.cc' > --- a/sql/item.cc 2013-07-03 07:46:20 +0000 > +++ b/sql/item.cc 2013-08-07 09:34:20 +0000 > @@ -252,7 +252,8 @@ String *Item::val_string_from_decimal(St > String *Item::val_string_from_date(String *str) > { > MYSQL_TIME ltime; > - if (get_date(&ltime, 0) || > + if (get_date(&ltime, > + field_type() == MYSQL_TYPE_TIME ? TIME_TIME_ONLY : 0) || > str->alloc(MAX_DATE_STRING_REP_LENGTH)) > { > null_value= 1; > > === modified file 'sql/item_func.cc' > --- a/sql/item_func.cc 2013-07-03 07:46:20 +0000 > +++ b/sql/item_func.cc 2013-08-07 09:34:20 +0000 > @@ -2480,6 +2480,13 @@ bool Item_func_min_max::get_date(MYSQL_T > ltime->time_type= MYSQL_TIMESTAMP_DATE; > ltime->hour= ltime->minute= ltime->second= ltime->second_part= 0; > } > + else if (compare_as_dates->field_type() == MYSQL_TYPE_TIME) > + { > + ltime->time_type= MYSQL_TIMESTAMP_TIME; > + ltime->hour+= (ltime->month * 32 + ltime->day) * 24; > + ltime->month= ltime->day= 0; > + } > + > > return 0; > } Regards, Sergei

1 0

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-md83/
by Oleksandr Byelkin 09 Aug '13

09 Aug '13

09.08.2013 14:30, timour(a)askmonty.org пишет: > At file:///home/tsk/mprog/src/10.0-md83/ > > ------------------------------------------------------------ > revno: 3552 > revision-id: timour(a)askmonty.org-20130809113013-ia2f7zzw3mv3in7u > parent: timour(a)askmonty.org-20130611081135-rge7p00h8e9nhypj > fixes bug: https://mariadb.atlassian.net/browse/MDEV-4648 > committer: timour(a)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 <t1, sj-mat, t2>. 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!

1 0

[Maria-developers] Is it a bug?
by Alexey Botchkov 09 Aug '13

09 Aug '13

Hi, SerG. The code in sql/sql_plugin.cc function read_maria_plugin_info() sym= dlsym(plugin_dl->handle, maria_plugin_declarations_sym); ... if (plugin_dl->mariaversion != MARIA_PLUGIN_INTERFACE_VERSION) { ... if ((sym= dlsym(plugin_dl->handle, maria_sizeof_st_plugin_sym))) sizeof_st_plugin= *(int *)sym; ... if (sizeof_st_plugin != sizeof(st_mysql_plugin)) { ... sym= cur; } } plugin_dl->plugins= (struct st_maria_plugin *)sym; So that when we enter the first 'if' but not the second (sizeof_st_plugin == sizeof(st_mysql_plugin) the sym still points at the maria_sizeof_st_plugin_sym which makes a bad st_maria_plugin pointer. I think it's a bug, isn't it? Best regards. HF

2 1