- developers - lists.mariadb.org

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

Re: [Maria-developers] GTID and removing binary logs
by Kristian Nielsen 08 Aug '13

08 Aug '13

Elena Stepanova <elenst(a)montyprogram.com> writes: > Reading recent Pavel Ivanov's reports (the last one is MDEV-4820, but > I think there were some others which you've already closed as fixed), > I started wondering if I conceptually misunderstood something > before. From our previous discussions I made a conclusion that > removing *all* binary logs before trying to replicate from the server > is very wrong and against the whole idea of GTID. Is it not so? If > not, it's definitely an area which didn't undergo any testing from me, > except for my very first clumsy attempts to get familiar with GTID, so > I need to fill the gap. Well, we _do_ want to support running a slave with --log-slave-updates=0, and then making that slave into a master. Indeed, you tested that early and it was horribly broken. However, my intention is that this should now be supported (and thus can be tested). There are MTR testcases for this. The reason I mention this is that the case of --log-slave-updates=0 is actually quite similar (from the server's point of view) to manually deleting the logs. So I do also intend to support removing binlogs as Pavel wants to do. The main problem with doing this (deleting binlogs or using --log-slave-updates=0) is that it makes it harder to detect certain user errors, because the information to know that it is an error is missing. I suppose the limitations should be pretty obvious: If user deletes binlogs on a server, then that server, acting as a master, can not replicate to slaves starting from an event that was deleted. So as long as the user does not try to do that, things should be fine. I think the main problems come if the user makes a mistake in this respect, and the server fails to detect the error. For example, suppose that server A is a slave, replicates up to position 0-2-10. Then it becomes a master, generates events up to 0-1-20. Then user deletes the binlogs on A, and tries to have server B replicate from A starting at position 0-2-10. In this case, server A will allow B to connect, effectively loosing the deleted events 0-1-11 .. 0-1-20. I do not see any way to avoid this. Server A has no way to know that those events ever existed, as the user deliberately deleted all information about them. (In fact the user might be doing this deliberately, in case the events were wrongly created and should be removed from the history). A workaround in this example is that the user sets @@gtid_slave_pos explicitly to 0-1-20 after deleting the logs, thus preserving the needed information. So in summary: Yes, we try to support deleting binlogs, however there is some responsibility on the part of the user to not delete information that they actually need. I think that is rather reasonable. It is how DELETE and SELECT work, as well :-) - Kristian.

1 0

Re: [Maria-developers] [Commits] Rev 3772: MDEV-4645: Incorrect reads of frozen binlog events; FDE corrupted in relay log in file:///home/bell/maria/bzr/work-maria-10.0-MDEV-4548/
by Jeremy Cole 08 Aug '13

08 Aug '13

Sanja, Re: https://mariadb.atlassian.net/browse/MDEV-4645 Re: http://lists.askmonty.org/pipermail/commits/2013-July/005093.html I saw your commit on the commits list (sorry, wasn't on the list before the mail went out, so I can't reply directly to that message). A couple of points related to the commit: - You seem to have an error in the get_header_len, as it's implemented only in the base class, and you've left functions with the correct signature for it but the wrong names in the two frozen classes (they were left named has_fixed_minimal_header). This would mean the change is completely broken. :) - The change to get_header_len I think is in general fine, although it does alter the point of the whole thing -- there is again no way to exactly identify which events have frozen headers, programmatically (i.e. you can't differentiate them from events who just "happen" to have header_len = LOG_EVENT_MINIMAL_HEADER_LEN). I think that doesn't matter for this patch, but does defeat the point of what I was trying to add. - I don't really understand why you've made the hex printing code so complex and completely unreadable (IMHO). This is not performance-sensitive code and in my opinion should favor readability over performance. All you seem to have saved in this change is to avoid printing some static formatting characters ("#", "|", spaces, etc.) inside the loop. However, I can hardly even figure out what it's supposed to be doing now. - Additionally, you've changed the output slightly -- normally the ASCII character section prints its ending "|" immediately after the last character; it seems now to be fixed position (leaving extra spaces before "|". This differs from the output of hexdump, and it somewhat ambiguous/confusing. - You've mixed tabs and spaces. :( Regards, Jeremy

2 8