April 2015 - developers - lists.mariadb.org

[Maria-developers] PLEASE REVIEW: (MDEV-7574) Security definer views don't work with CONNECT ODBC tables
by Alexander Barkov 26 Jul '15

26 Jul '15

Hello Sergei, Please review a patch that fixes the problem described in MDEV-7574. The idea is that a SELECT from a view over a CONNECT table now checks FILE privileges of the view definer (unless CREATE VIEW states SQL SECURITY INVOKER). It looks like a very good idea and gives more possible security options. The administrator can create a VIEW and give access to it to some user, without giving FILE privilege to this user. I'm not really sure about the patch, but it seems to do the trick :) From what I understood, FILE_ACL is written (among the other privileges) into thd->security_ctx.privilege in TABLE_LIST::prepare_security(). In case of a DEFINER view, thd->security_ctx.privilege is filled exactly with the definer privileges, and to the invoker privileges otherwise. So inside ha_connect::check_privileges() the fact that there is FILE_ACL in thd->security_ctx.privilege means that TABLE_LIST::prepare_security() was previously called and FILE_ACL is set to DEFINER or INVOKER, according to the view definition. This is exactly what we need. I'm not sure about the opposite: if there is no FILE_ACL in thd->security_ctx.privilege, what does it mean? Does it mean that there is no FILE_ACL for the effective user? Or can it also mean that TABLE_LIST::prepare_security() was not called? Thanks. On 02/12/2015 04:04 AM, Olivier Bertrand wrote: > Hi Alexander, > > Can you take care of this issue? I know you wrote the > ha_connect::check_privileges function and I personnally have not the > faintest idea about how this must be checked. > > Thanks, > Olivier > > > -------- Message transféré -------- > Sujet : [JIRA] (MDEV-7574) Security definer views don't work with > CONNECT ODBC tables > Date : Wed, 11 Feb 2015 23:21:00 +0200 (EET) > De : Elena Stepanova (JIRA) <jira(a)mariadb.atlassian.net> > Pour : bertrandop(a)gmail.com > > > > [https://mariadb.atlassian.net/browse/MDEV-7574?page=com.atlassian.jira.plug… ] > > Elena Stepanova reassigned MDEV-7574: > ------------------------------------- > > Assignee: Olivier Bertrand > Fix Version/s: 10.0 > >> Security definer views don't work with CONNECT ODBC tables >> ---------------------------------------------------------- >> >> Key: MDEV-7574 >> URL:https://mariadb.atlassian.net/browse/MDEV-7574 >> Project: MariaDB Server >> Issue Type: Bug >> Components: Storage Engine - Connect >> Affects Versions: 10.0.16 >> Reporter: Geoff Montee >> Assignee: Olivier Bertrand >> Labels: connect-engine >> Fix For: 10.0 >> >> >> One possible way to get around the requirement for having the FILE privilege to access ODBC tables with CONNECT would be to have them called indirectly via a security definer view. However, it does not currently work. >> Create a security definer view to access the ODBC table, then create a new user: >> {code} >> [gmontee@localhost ~]$ mysql -u root tmp >> Reading table information for completion of table and column names >> You can turn off this feature to get a quicker startup with -A >> Welcome to the MariaDB monitor. Commands end with ; or \g. >> Your MariaDB connection id is 16 >> Server version: 10.0.15-MariaDB-log MariaDB Server >> Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. >> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. >> MariaDB [tmp]> SHOW CREATE TABLE datetime_table; >> +----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >> | Table | Create Table | >> +----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >> | datetime_table | CREATE TABLE `datetime_table` ( >> `id` int(10) NOT NULL, >> `modifiedon` datetime DEFAULT NULL >> ) ENGINE=CONNECT DEFAULT CHARSET=latin1 CONNECTION='DSN=connect_test_azure;UID=connect_test;PWD=Password1' `TABLE_TYPE`='ODBC' `TABNAME`='dbo.datetime_table' | >> +----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >> 1 row in set (0.00 sec) >> MariaDB [tmp]> DROP USER 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> CREATE OR REPLACE >> -> DEFINER = CURRENT_USER >> -> SQL SECURITY DEFINER >> -> VIEW datetime_view >> -> AS SELECT * FROM datetime_table; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> CREATE USER 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> GRANT SELECT ON datetime_view TO 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> \q >> Bye >> {code} >> Now connect with the new user, and try to use the view: >> {code} >> [gmontee@localhost ~]$ mysql -u connecttest tmp >> Reading table information for completion of table and column names >> You can turn off this feature to get a quicker startup with -A >> Welcome to the MariaDB monitor. Commands end with ; or \g. >> Your MariaDB connection id is 17 >> Server version: 10.0.15-MariaDB-log MariaDB Server >> Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. >> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. >> MariaDB [tmp]> SELECT * FROM datetime_view; >> ERROR 1045 (28000): Access denied for user 'connecttest'@'localhost' (using password: NO) >> MariaDB [tmp]> \q >> Bye >> {code} >> It didn't work, so give the user privileges on the underlying ODBC table: >> {code} >> [gmontee@localhost ~]$ mysql -u root tmp >> Reading table information for completion of table and column names >> You can turn off this feature to get a quicker startup with -A >> Welcome to the MariaDB monitor. Commands end with ; or \g. >> Your MariaDB connection id is 18 >> Server version: 10.0.15-MariaDB-log MariaDB Server >> Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. >> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. >> MariaDB [tmp]> GRANT FILE ON *.* TO 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> GRANT SELECT ON datetime_table TO 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> \q >> Bye >> {code} >> Now try using the view again: >> {code} >> [gmontee@localhost ~]$ mysql -u connecttest tmp >> Reading table information for completion of table and column names >> You can turn off this feature to get a quicker startup with -A >> Welcome to the MariaDB monitor. Commands end with ; or \g. >> Your MariaDB connection id is 19 >> Server version: 10.0.15-MariaDB-log MariaDB Server >> Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. >> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. >> MariaDB [tmp]> SELECT * FROM datetime_view; >> +----+---------------------+ >> | id | modifiedon | >> +----+---------------------+ >> | 1 | 2014-01-01 00:00:00 | >> | 2 | 2016-01-01 00:00:00 | >> +----+---------------------+ >> 2 rows in set (0.24 sec) >> {code} > > > > -- > This message was sent by Atlassian JIRA > (v6.4-OD-14-082#64012) > > >

2 9

[Maria-developers] Please review: MDEV-7824 [Bug #68041] Zero date can be inserted in strict no-zero mode through a default value
by Alexander Barkov 25 Jun '15

25 Jun '15

Hi Sergei, Please review a patch for mdev-7824. It's based on a MySQL patch for http://bugs.mysql.com/bug.php?id=68041 and is a blocker for: MDEV-3929 Add full support for auto-initialized/updated timestamp and datetime Thanks.

2 9

[Maria-developers] MDEV-6877 - binlog_row_image implementation advice
by Vicențiu Ciorbaru 25 Jun '15

25 Jun '15

Hi Sergei! This past week I've done quite a bit of reading regarding the replication code and how the binlog is used by both mysqlbinlog and the slaves in order to do replication. I think I now have a good enough understanding of the flow of the code for both MySQL and MariaDB to actually start coding the feature into MariaDB. I do have a couple of unknowns still. I don't quite understand what's the use for the TABLE_MAP event. My intuition tells me its some sort of id we assign to a table name (test.t1 for example) that gets used afterwards in the binlog row events. We seem to be using a bitmap of columns that we want to log into the binlog. MySQL does extend the TABLE class to flip the bits according to the binlog_row_image variable. That seems like the first place to start with the addition. I could not find any other "hidden" logic that we use to choose how we log row operations in the binlog. What I would like to know is if there are any other pitfalls that I am supposed to watch out for, or if there is anything else I may be missing regarding the logging part. When it comes to actually doing the replication, I concluded that Log_event::do_apply_event is the place where we begin translating the event from the binlog to an SQL statement. Another concern that I have is how to test the implementation. Right now, I run the test, get the binlog file and print it with mysqlbinlog and see if the output is what I expect. Do we have something within mysql-test-run that automates this? Regards, Vicentiu

2 7

[Maria-developers] Memory barrier problem in InnoDB/XtraDB mutex implementation causing hangs
by Kristian Nielsen 27 May '15

27 May '15

I have been debugging some test failures seen in Buildbot: https://mariadb.atlassian.net/browse/MDEV-7026 After some debugging, this is what I think is going on. I will refer to MariaDB 5.5 sources, though the problem is also in 10.0. InnoDB/XtraDB mutexes are taken in mutex_enter_func() and unlocked in mutex_exit_func(). Simplifying for clarity, here are the relevant parts of the logic: ENTER: # First spin wait, hoping to get the mutex without yielding. os_compare_and_swap_ulint(&mutex->waiters, 0, 1); if (os_atomic_test_and_set_byte(&mutex->lock_word, 1)) sync_array_wait_event() RELEASE: os_atomic_lock_release_byte(&mutex->lock_word); os_rmb; waiters = *(volatile *)&mutex->waiters; if (waiters) mutex_signal_object(mutex); The interesting point here is how to ensure that we do not lose the wakeup of a waiting thread when the holding thread releases the mutex. The idea is that the waiting thread first sets mutex->waiters=1. Then it checks if the mutex is free - if not, it goes to sleep. The thread that releases the lock first marks the mutex free. Then it checks if there are any waiters, and if so wakes them up. For this to work, we need to ensure that the setting of waiters=1 has completed before the load of lock_word can start - a full memory barrier. Likewise, we need the setting of lock_word to 0 to complete before the load of mutex->waiters - again a full memory barrier. Otherwise we can get something like this: ENTER RELEASE Start store to mutex->waiters Start store to lock_word Load mutex->lock_word Store to lock_word becomes visible Load mutex->waiters Store to waiters becomes visible Check lock word==1 Check waiters==0, skip wakeup Sleep (forever) Or this: ENTER RELEASE Start store to lock_word Start store to mutex->waiters Load mutex->waiters Store to waiters becomes visible Load mutex->lock_word Store to lock_word becomes visible Check lock word==1 Sleep (forever) Check waiters==0, skip wakeup (So both full barriers are needed, the one in ENTER to prevent the first example, the one in RELEASE to prevent the second). It looks like for x86, the full barriers were broken in MariaDB 5.5.40 and 10.0.13. os_compare_and_swap_ulint() is defined as either __sync_bool_compare_and_swap() or atomic_cas_ulong(), both of which implies a full barrier. So ENTER looks ok. os_atomic_lock_release_byte() however is now defined as __sync_lock_release(). This is _not_ a full barrier, just a release barrier. So the RELEASE case seems to be incorrect, allowing the second deadlock example to occur. Previously, RELEASE used os_atomic_test_and_set_byte(), which is __sync_lock_test_and_set(). This is defined in GCC docs as an "aquire" barrier only, which is also wrong, obviously. But it happens to generate an XCHG instruction on x86, which is a full barrier. This is probably why it works on x86 (and probably why it did not work on PowerPC). Here is a small test program, and the assembly from GCC 5.7 on amd64: void test(unsigned *p, unsigned *q) { while (__sync_lock_test_and_set(q, 1)) { } *p++; __sync_lock_release(q); } test: movl $1, %edx .L2: movl %edx, %eax xchgl (%rsi), %eax testl %eax, %eax jne .L2 movl $0, (%rsi) ret As can be seen, the __sync_lock_test_and_set() generates a full barrier, but the __sync_lock_release() generates nothing (as this is sufficient for release semantics for the rather strong memory order on x86). So the InnoDB mutexes look completely broken from MariaDB 5.5.40 and 10.0.13 :-( This is consistent with the observations in MDEV-7026. A thread is waiting for wakeup on a mutex that is already marked free. Apparently this is not a new problem. This comment in mutex_exit_func() makes me want to cry: /* A problem: we assume that mutex_reset_lock word is a memory barrier, that is when we read the waiters field next, the read must be serialized in memory after the reset. A speculative processor might perform the read first, which could leave a waiting thread hanging indefinitely. Our current solution call every second sync_arr_wake_threads_if_sema_free() to wake up possible hanging threads if they are missed in mutex_signal_object. */ So someone found the mutex implementation broken, but instead of fixing it, they implemented a horrible workaround to try and break any deadlocks that might occur. (The reason that the deadlocks are not broken in the MDEV-7026 seems to be that it occurs during startup, before starting the srv_error_monitor_thread() that does the sync_arr_wake_threads_if_sema_free()). Now, what is also interesting is that this seems to explain very nicely the many server lockups we have seen for users that upgrade to recent MariaDB versions. I was doing a very detailed investigation of one such case where the user was able to supply unusually detailed information. I found a thread that was stuck waiting on a mutex, but no other threads seemed to be holding that mutex. This is exactly what would be seen in case of a lost wakeup due to this issue. Furthermore, the sync_arr_wake_threads_if_sema_free() mechanism, as well as the normal InnoDB "long semaphore wait", was itself blocked on that same mutex wait, which explains why they were not effective for the user in that particular case. So it looks like we need to revert the incorrect patch and release new 5.5.40a and 10.0.15 releases ASAP, to solve these hangs for users. And do a proper patch for PowerPC with proper full memory barriers. (Incidentally, the os_rmb in RELEASE seems to also be part of some PowerPC patch, it also looks completely wrong). However, more importantly, this issue clearly shows some fundamental problems in our development procedures that we need to fix ASAP. Just look at it. We have users (and customers!) that suffer from strange hangs. This is their production systems that are down. Support and developers are unable to help them due to the difficulty of debugging rare race conditions in production systems. And all the time the bug was staring us in the face, easily reproducable in our own Buildbot! But we deliberately chose to ignore those failures. The only thing that matters is "when can you push", and getting more releases out. Never mind what kind of crap is then pushed out to users. I am deeply ashamed of treating our users like this. And extremely unhappy. I even wrote about this (the importance of not ignoring Buildbot failures) just a few weeks ago. This was completely ignored, I got zero replies, and the weekly calls continued with mindless juggling of Jira numbers and buggy releases. As a result, our users suffer. We need to stop this. Please? - Kristian.

4 16

[Maria-developers] MDEV-7807 information_schema.processlist truncates queries with binary strings
by Alexander Barkov 07 May '15

07 May '15

Hi Sergei, Please review the patch for: MDEV-7807 information_schema.processlist truncates queries with binary strings The patch is for 10.1, as agreed with the reporter. Previously in 10.1 we fixed binary->string conversion behaviour not to truncate on bad bytes, and replace bad bytes to question marks instead. That fixed half of the problem reported. This patch adds a new new column "PROCESSLIST.INFO_BINARY blob". Thanks.

2 1

[Maria-developers] Please review: MDEV-7778 impossible create copy of table, if table contain default value for timestamp field
by Alexander Barkov 04 May '15

04 May '15

Hi Sergei, Please review a patch for MDEV-7778. As agreed on IRC, this is a merge from the latest MySQL, which has already fixed the problem. Greetings.

2 1

[Maria-developers] [GSoC 2015] Accepted Student- Self Introduction
by Delveri chick 30 Apr '15

30 Apr '15

Hello everyone ! I am Delveri Chick, a junior software engineering student from Cameroon. I have been accepted into GSoC 2015 to hack on project titled : Improved Temporary Tables. Here <http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/…> is my GSoC proposal. Sergei Golubchik will be mentoring me for this project. I am really excited to spend my summer hacking on MariaDB, and hoping to learn a lot of things from the developer community. Thanks. Delveri

2 1

Re: [Maria-developers] [Commits] 13ecde8: Fix compiler warnings.
by Vicențiu Ciorbaru 30 Apr '15

30 Apr '15

Hi Jan! I have one concern with this patch. See below: On Thu, 30 Apr 2015 at 11:45 Jan Lindström <jan.lindstrom(a)mariadb.com> wrote: > revision-id: 13ecde851f08a7952f774707b19734f351bb6598 > parent(s): 5027e0b035f96e2583eff2d1ac71c7c44a093ac8 > committer: Jan Lindström > branch nick: 10.0-git > timestamp: 2015-04-30 11:44:34 +0300 > message: > > Fix compiler warnings. > > --- > storage/innobase/sync/sync0sync.cc | 27 +++++++++++++-------------- > storage/xtradb/sync/sync0sync.cc | 27 +++++++++++++-------------- > 2 files changed, 26 insertions(+), 28 deletions(-) > > diff --git a/storage/innobase/sync/sync0sync.cc > b/storage/innobase/sync/sync0sync.cc > index 121f8e9..78d86f3 100644 > --- a/storage/innobase/sync/sync0sync.cc > +++ b/storage/innobase/sync/sync0sync.cc > @@ -862,10 +862,10 @@ sync_thread_levels_g( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > I think this here has to be arr->at(i), or &(*arr)[i]. Doing &arr[i] will actually get the i'th std::vector<> which does not exist, since arr is a pointer to only one std::vector<>. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level <= limit) { > if (warn) { > @@ -897,10 +897,10 @@ sync_thread_levels_contain( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -944,10 +944,10 @@ sync_thread_levels_contains( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -993,10 +993,10 @@ sync_thread_levels_nonempty_gen( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!dict_mutex_allowed > @@ -1053,10 +1053,10 @@ sync_thread_levels_nonempty_trx( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!has_search_latch > @@ -1331,7 +1331,7 @@ sync_thread_add_level( > > sync_level.latch = latch; > sync_level.level = level; > - array->elems.push_back(sync_level); > + array->push_back(sync_level); > > mutex_exit(&sync_thread_mutex); > } > @@ -1377,14 +1377,14 @@ sync_thread_reset_level( > > array = thread_slot->levels; > - for (std::vector<sync_level_t>::iterator it = array->elems.begin(); > it != array->elems.end(); ++it) { > + for (std::vector<sync_level_t>::iterator it = array->begin(); it > != array->end(); ++it) { > sync_level_t level = *it; > > if (level.latch != latch) { > continue; > } > > - array->elems.erase(it); > + array->erase(it); > mutex_exit(&sync_thread_mutex); > return(TRUE); > } > @@ -1471,7 +1471,6 @@ sync_thread_level_arrays_free(void) > > /* If this slot was allocated then free the slot memory > too. */ > if (slot->levels != NULL) { > - > slot->levels->elems.erase(slot->levels->elems.begin(),slot->levels->elems.end()); > delete slot->levels; > } > } > diff --git a/storage/xtradb/sync/sync0sync.cc > b/storage/xtradb/sync/sync0sync.cc > index d0e3b71..9dcdd9c 100644 > --- a/storage/xtradb/sync/sync0sync.cc > +++ b/storage/xtradb/sync/sync0sync.cc > @@ -970,10 +970,10 @@ sync_thread_levels_g( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level <= limit) { > if (warn) { > @@ -1005,10 +1005,10 @@ sync_thread_levels_contain( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -1052,10 +1052,10 @@ sync_thread_levels_contains( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -1101,10 +1101,10 @@ sync_thread_levels_nonempty_gen( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!dict_mutex_allowed > @@ -1161,10 +1161,10 @@ sync_thread_levels_nonempty_trx( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!has_search_latch > @@ -1456,7 +1456,7 @@ sync_thread_add_level( > > sync_level.latch = latch; > sync_level.level = level; > - array->elems.push_back(sync_level); > + array->push_back(sync_level); > > mutex_exit(&sync_thread_mutex); > } > @@ -1502,14 +1502,14 @@ sync_thread_reset_level( > > array = thread_slot->levels; > > - for (std::vector<sync_level_t>::iterator it = > array->elems.begin(); it != array->elems.end(); ++it) { > + for (std::vector<sync_level_t>::iterator it = array->begin(); it > != array->end(); ++it) { > sync_level_t level = *it; > > if (level.latch != latch) { > continue; > } > > - array->elems.erase(it); > + array->erase(it); > mutex_exit(&sync_thread_mutex); > return(TRUE); > } > @@ -1597,7 +1597,6 @@ sync_thread_level_arrays_free(void) > > /* If this slot was allocated then free the slot memory > too. */ > if (slot->levels != NULL) { > - > slot->levels->elems.erase(slot->levels->elems.begin(),slot->levels->elems.end()); > delete slot->levels; > } > } >

1 0

Re: [Maria-developers] [Commits] 8a18bbc: MDEV-8079: Crash when running MariaDB Debug with InnoDB on Windows
by Vicențiu Ciorbaru 30 Apr '15

30 Apr '15

Here is a patch that fixes all compilation related issues. Unfortunately it's based on 10.1. It might need a bit of tweaking to merge directly into 10.0

1 0

[Maria-developers] GSoC 2015 student
by Blessing Atie 29 Apr '15

29 Apr '15

Hello everyone, My surname is Blessing and I am a student at University of Buea. I am very happy to be selected by MariaDb to part take in GSoC 2015. I will be working on Improving table Functions mentored Sergei Golubchik and I look forward to know him soon on #maria as well as the other students. I equally look forward on using this as an opportunity to learn more about open source and MariaDB community. Can't wait to get hands dirty on MariaDB source. Thanks. Blessing

2 1