I go away for three days and ...

So I've set up this cast-aside laptop as a machine to do pulls from BitKeeper and do builds and installs and it's working pretty well. I was able to do pulls of six different versions of MySQL and build them. They are now happily running simultaneously.

Then I went away for three days, taking my younger daughter to boarding school where she is starting as a freshman in high school. At the same time my older daughter is off to college so the nest is now basically empty. But I digress.

I said 'was' because shortly after that a couple bugs manifested, one as noted before and one new one which I was pleased to report and have verified. I have been following the development of the MySQL Build Farm Initiative and on Sheeri Kritzer's recommendation, I added this machine to the inventory of available machines. Bug #21642, now fixed in the 5.1 tree, continues to be an issue in the 5.2 tree, and now the 5.1 tree is affected by Bug #21855, and I'll see if I can't do some poking and prodding into what's causing that one. I've taken the opportunity when these issues arise to get under the hood and look into what's going on. In the case of Bug #21642 I had my own workaround patch in place almost immediately while waiting for the official fix, and I'll be doing some research into Bug #21855 as well.

The Build Farm idea sounds like a good one, and while I wait to see how it will develop, I'm going ahead with building and installing more or less daily pulls of the available source trees.

Effect of Perceived Values

In my experience there has been a driving factor, a mindset of those who make the purchasing decisions and are not necessarily technically knowledgeable, that the value of an item somehow equates to the money spent acquiring it. A company I worked for years ago catered to this mindset by way of pricing their product according to factors such as speed, capacity, and price of the target computer. The same software was delivered to all customers, but the understanding was that owners of computers would somehow expect software to be valued in relation to their computer. Owners of expensive computers would expect to have to purchase expensive software for it, and distrust something viewed as too cheap, whereas owners of lower priced systems would not want to pay as much for the software by the same token.

Times have changed but the value/price mindset continues. One place I was at a few years ago seemed caught up in the mindset. They hired a young DBA whose expertise was mostly in Visual Basic and SQL Server, and on his recommendation spent a lot of money on hardware and software, dedicated high-end server system, workstation systems, etc. I didn't know then some of the things I know now, and I'd have come up with a rather less pricey solution if asked today. Back then I probably would have come up with yet a third solution involving mostly development on my part and little if any
hardware investment. Shortly after that they started going down the open-source path with Apache and Perl. They probably would have arrived at MySQL or something similar in time, but a corporate mindset is a hard thing to break.

The idea of switching to an open source database for a web application has a lot to do with highering a web experts and then acquiring for him the tools he requests to fulfill his job. But still the web system is viewed as separate from the 'real' data processing, somehow inferior. The OS database is no less efficient or reliable, of course, but unless that is understood by managers or decision makers it matters little. There may be a slow increase over time, the occasional rogue department that switches over, but it's counter to the corporate culture of volume license deals with large software vendors. A lot remains to be seen how the landscape continues to unfold, but there are signs that times are changing, mindsets are changing.

A busy afternoon

Having gotten my daughter a new laptop to take off to college where she starts as a freshman in a couple of weeks, I now have her old laptop, still quite serviceable albeit older, larger, heavier, etc. So I set about setting it up as a system where I can do BK pulls of various MySQL versions, be continuously running and testing new pulls from the 5.1 and 5.2 trees.

The first thing I did was to take the laptop, a Toshiba Satellite with a 30GB hard drive, Celeron processor and 256MB RAM, reformat it and install Slackware 10.2. This is my preferred operating system except for a couple of systems that are rather low on my priority to convert, where it's vital to keep them running as Windows because of a number of applications. I set up the following partitions:

hda1  6.6GB /
hda2  6.6GB /usr
hda3  512MB (swap)
hda4 13.3GB /usr/local

The swap partititon is my standard formula, double the size of the RAM, and located approximately in the center of the drive. This is a bit of a departure from my earlier configurations in which I typically created two data partitions, with hda1 incorporating /, /usr, and /usr/local, but latter partition containing directories symbolically linked into the structure on hda1.

Slackware came up okay. I was a little concerned having hda4's mountpoint being on hda3 having in turn it's mountpoint on hda1, that the mount process might somehow mount the partitions out of order for some reason, or have some other chicken&egg sort of problem.

Then I started the bundled MySQL. This is version 4.1.14 of MySQL, and as has been pointed out elsewhere, it does not start automatically out of the box owing to the fact that the Slackware installation does not run mysql_install_db and also it is required to set the permissions on the data directory to correct the error 13 'permission denied' abort when trying to start MySQL.

I then downloaded and installed bk_client-1.1 and pulled the 5.1 and 5.2 sources. I installed Bison 2.3 to correct the sql_yacc.yy compile error I noted previously, and promptly ran into Bug #21642, reported hours earlier, of the undefined reference to `srv_flush_log_at_trx_commit' error that happens when configure is run with no arguments.

Now I just need to figure out what arguments it is necessary to apply in order to make it build properly.

Using Triggers with FEDERATED Tables

In a recent blog entry I discussed some research I had done into the behavior of MySQL FEDERATED tables. Since then the question arose in the forums regarding the use of triggers with FEDERATED tables, so I performed some additional tests to see how triggers would behave.

The question was asked if triggers could be used with FEDERATED tables, and I verified that triggers could indeed be created on FEDERATED tables. With the assertion that the a trigger on a FEDERATED table did not actually fire, I set up a base table and an associated FEDERATED tables with triggers attached to both tables and verified they did in fact get called.

A 'before insert' trigger on a FEDERATED table gets called before the corresponding 'before insert' trigger on the base table, and this is rather what I would expect. If the FEDERATED table's trigger makes an alteration to the row, the altered version is what the base table's trigger is presented with.

An 'after insert' trigger on a FEDERATED table gets called after the corresponding 'after insert' trigger on the base, and this is again what I would expect. However, there is an anomaly here. If the base table's 'before insert' trigger made alterations to the row which subsequently were written to the table, the base table's 'after insert' trigger sees these changes, but the FEDERATED table's 'after insert' trigger does not. It only sees any alterations made by the FEDERATED table's trigger.

So I can summarize my testing of before and after insert triggers by concluding that information flows during an insert into a FEDERATED table from the server with the FEDERATED table to the server with the base table, but not vice versa.