February 2009 - developers - lists.mariadb.org

[Maria-developers] WL#3859: Plug-in Service API discussion
by Kristian Nielsen 12 Mar '09

12 Mar '09

While we were discussing a generic I/O layer in MariaDB, Sergei brought up the issue of WL#3859. This worklog carries a principal issue that I wanted to mention and discuss. Sergei, if I understood you correctly, you said that Sun MySQL would never take a new internal API that does not follow the WL#3859 framework. Correct? My understanding (which may or may not be correct) is that at least part of MySQL/Sun wants to develop the storage engine plugin layer (and all other plugin layers) to be a complete ABI, that is complete binary compatibility. So that the user can obtain a pre-compiled plugin independently and load it into the server without risk of crashing if plugin is compiled against a different source version of the server (but may get an error message if versions are incompatible). This basically means that all data and code needs to be exported via the WL#3859 framework, not using the system linker as is currently done. Advantages include - Avoiding crash on incompatible version is good. - Supports selling proprietary (non Open Source) plugins. - Works on Windows where the system linker cannot export symbols from executables (though there is a standard workaround of just compiling the server into a library that is called from a stub main executable). Disadvantages include - Supports selling proprietary (non Open Source) plugins (yes, can be an advantage or disadvantage depending on point-of-view ;-). - Will tend to discourage making desirable changes, as the procedure becomes more complicated (more work to track versioned API, less flexibitily in what C++ language constructs can be used); and there will be the desire to minimize binary incompatibility. It would be great if some of you still inside Sun could confirm or reject that this is the way things are. This raises at least two important questions for MariaDB: 1. Do we want to adopt this direction, moving all existing exposed server internals into this framework, and implementing any new ones within it as well? Or reserve the right to use old-style direct linking where it makes more sense? (We can of course in any case use the WL#3859 framework where it makes sense, the issue is the principle of using it for everything eventually). 2. It seems impossible that we can keep the Sun/MySQL API versions and the MariaDB API versions 100% synchronised. So how will we handle version compatibility (ie. Sun/MySQL version 0x0109 may be different from Maria version 0x0109 due to different paces of development)? Will all plugins need to track two different versions, one for Sun/MySQL and one for MariaDB? Or will we somehow coordinate between the two teams to avoid version conflicts? Any opinions? My personal opinion is that I am sceptical if this worklog is a good idea; most of the big projects of this kind that have been successful have used the old MySQL approach (Apache, Perl, the Linux kernel). Though I'm not 100% decided one way or the other yet. But more importantly I think we need to have a conscious decision on how to deal with this in MariaDB, as it is a fundamental design issue that will impact many other desicions along the way. - Kristian.

2 3

[Maria-developers] Fw: Launchpad offline 00.00 - 01.00 UTC 26th February 2009
by Kurt von Finck 25 Feb '09

25 Feb '09

Begin forwarded message: Date: Tue, 24 Feb 2009 18:09:57 +0000 From: Matthew Revell To: redacted internal Canonical list Subject: Launchpad offline 00.00 - 01.00 UTC 26th February 2009 Launchpad will be offline from 00.00 - 01.00 UTC on Thursday 26th February. This is to allow us to roll-out the code for our latest release, Launchpad 2.2.2. Please see the Launchpad blog -- http://blog.launchpad.net -- for details of the release! -- Matthew Revell - Launchpad.net - free software collaboration and project hosting -- Launchpad-announce mailing list Launchpad-announce(a)lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-announce -- ./k kurt von finck http://www.mneptok.com public key: keyserver.ubuntu.com key id: 5229D26A fingerprint: 127A A484 ADBF A5AD E7FB 8CD2 8913 18F4 5229 D26A Music is the space between the notes. - Debussy

1 0

Re: [Maria-developers] bzr commit into MySQL/Maria:mysql-maria branch (monty:2725) Bug#40711
by Michael Widenius 24 Feb '09

24 Feb '09

Hi! >>>>> "Guilhem" == Guilhem Bichot <guilhem(a)sun.com> writes: <cut> >> +++ b/storage/maria/ma_close.c 2009-02-01 07:29:56 +0000 >> @@ -155,7 +155,7 @@ int maria_close(register MARIA_HA *info) >> MARIA_STATE_HISTORY_CLOSED *history; >> /* >> Here we ignore the unlikely case that we don't have memory to >> - store the case. In the worst case what happens is that any transaction >> + store the state. In the worst case what happens is that any transaction >> that tries to access this table will get a wrong status information. >> */ >> if ((history= (MARIA_STATE_HISTORY_CLOSED *) >> @@ -166,6 +166,8 @@ int maria_close(register MARIA_HA *info) >> if (my_hash_insert(&maria_stored_state, (uchar*) history)) >> my_free(history, MYF(0)); >> } >> + /* Marker for concurrent checkpoint */ >> + share->state_history= 0; >> } >> } >> pthread_mutex_unlock(&THR_LOCK_maria); Guilhem> So, what was the scenario? Guilhem> I imagined this one: Thread1 has just closed the table, but Thread2 had Guilhem> started a checkpoint, so Thread1 leaves the share in existence; Thread2 Guilhem> looks at share->state_history, but why would that point to freed memory? Guilhem> Is it because there is a Thread3 which did this freeing? No, the problem happens with only two threads. T1 one goes into the above code and creates a history entry that points to share->state_history. In checkpoint thread we will then execute the following code: _ma_remove_not_visible_states_with_lock(share, FALSE); Which uses share->state_history entry and may even free it. If free happens, we are likely to get a crash as history entry now points to freed memory. Regards, Monty

1 0