Welcome to the 186th Edition of Log Buffer. Lots to report this week, so read on…

In Oracle news:

We begin with Gary Myers at the Sydney Oracle Lab who mixes GUI and CLI and shows how to manage your database from EMACS. You have to read a post that starts with: “There is a place of shadow, a place between the dark lands of the command-line interface, and the shining brightness of the GUI. In the days of yore, many dwelled in the shadow lands, but almost all have been attracted to the lights of SQL Developer…”

Tanel Poder gives a step by step tour of his …

The White House contributes to OSS. Growth for Pentaho and MuleSoft. And more.

Follow 451 CAOS Links live @caostheory on Twitter and Identi.ca
“Tracking the open source news wires, so you don’t have to.”

# The White House released some of the custom code it has developed for whitehouse.gov as open source.

# Pentaho reported 229% bookings growth and 177% Enterprise Edition customer growth in Q2.

# MuleSoft grew bookings by 140% in Q1.

# The beta of Red Hat Enterprise Linux 6 is now available, without Xen.

…

We’re now about a week away from WordCamp San Francisco 2010. I am extremely excited about the speaker lineup this year (6-7 not listed yet), we’ll have a jazz performance, awesome shirts… best WordCamp SF yet. Get your tickets ASAP if you hope to attend.

We are pleased to announce the availability of the 1.1.1 Alpha Release of InfiniDB Community Edition.  This is our second alpha release for 1.1 and is not recommended for production work. 

We've been hard at work on 1.1 and we are excited to give you a sneak peak at what we've been up to.  This release includes the following new functionality:

Improved performance for queries run during an active transaction.
Bulk load (cpimport) support for imports vi...

I've got many questions during User Conference about InnoDB Purge Thread feature. And I've promised finally to write a short blog post explaining this feature in details and specially why do you need it :-) Don't know if it'll be short, but hope you'll have less questions by the end of this article.. :-)

So far, during the User Conference we presented the following graph to demonstrate the InnoDB Purge Thread in action:

This graph represents 40 min of non-stop activity under dbSTRESS Read+Write workload with 32 user sessions. On the left part of graph you may see the TPS level observed while a purge thread is turned off. And on the right part when it's turned on. From the graph you may see that once purge thread is activated it makes transactional throughput free of all periodic freezes of activity (and seen here as TPS level drops)... And curiously many people manly retain just "ok, it makes the picture more beautiful, but it …

From Sunday 11.4.2010 to Thursday 22.4.2010, I used my Twitter account @kajarno to send

• 26 Swedish tweets
• 41 German tweets
• 69 English tweets

(not counting direct replies) of which a clear majority (but not all) were of a volcanic nature.

Most Swedish readers can follow German and English too, and most German readers also follow English. Hence the large number of English tweets and the larger number of German tweets.

Here’s a subset of the English tweets. The dates and times are local (California 9 h different from Munich; Chicago 7 h different).

Thursday 15.4.2010

• 13:12 Kaj Arnö wonders whether LH459 will leave at all MUC-SFO tonight 21:00, and if so, which route #iceland #volcao #ash
• 20:18 Damn, flight was cancelled. #lh #iceland #volcano SFO-MUC LH459 …

This is the third and final article in a series about group commit in MySQL. The first article discussed the background: group commit in MySQL does not work when the binary log is enabled. The second article explained the part of the InnoDB code that is responsible for the problem.

So how do we fix group commit in MySQL? As we saw in the second article of this series, we can just eliminate the prepare_commit_mutex from InnoDB, extend the binary logging to do group commit by itself, and that would solve the problem.

However, we might be able to do even better. As explained in the first article, with …

This is the second in a series of three articles about ideas for implementing full support for group commit in MariaDB. The first article discussed the background: group commit in MySQL does not work when the binary log is enabled. See also the third article.

Internally, InnoDB (and hence XtraDB) do support group commit. The way this works is seen in the innobase_commit() function. The work in this function is split into two parts. First, a "fast" part, which registers the commit in memory:

    trx->flush_log_later = TRUE;
    innobase_commit_low(trx);
    trx->flush_log_later = FALSE;

Second, a "slow" part, which writes and fsync's the commit to disk to make it durable:

    trx_commit_complete_for_mysql(trx)

While …

This is the first in a series of three articles about ideas for implementing full support for group commit in MariaDB (for the other parts see the second and third articles). Group commit is an important optimisation for databases that helps mitigate the latency of physically writing data to permanent storage. Group commit can have a dramatic effect on performance, as the following graph shows:

The rising blue and yellow lines show transactions per second when group commit is working, showing greatly improved throughput as the parallelism (number of concurrently running transactions) increases. The flat red and green lines show transactions per second with no group commit, with no scaling at all as parallelism increases. As can be seen, the effect of group commit on …

I had an interesting IRC discussion the other day with Monty Taylor about what turned out to be a limitation in Valgrind with respect to debugging memory leaks in dynamically loaded plugins.

Monty Taylor's original problem was with Drizzle, but as it turns out, it is common to all of the MySQL-derived code bases. When there is a memory leak from an allocation in a dynamically loaded plugin, Valgrind will detect the leak, but the part of the stack trace that is within the plugin shows up as an unhelpful three question marks "???":

==1287== 400 bytes in 4 blocks are definitely lost in loss record 5 of 8
==1287==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
==1287==    by 0x126A2186: ???
==1287==    by 0x7C8E01: ha_initialize_handlerton(st_plugin_int*) (handler.cc:429)
==1287==    by 0x88ADD6: plugin_initialize(st_plugin_int*) …