Monthly Archives: January 2011

They took my Kodachrome away

Posted on by
Reply

It’s done. It’s gone. You can still find rolls on eBay and the like, but you’re not going to get them developed as colour slides. Dwayne’s Photo stopped accepting Kodachrome on December 30th 2010. I have a set on flickr of my Kodachrome shots. The scans do not do them justice. They look way better projected. I will also talk about the demise of Kodachrome without mentioning the Paul Simon song. oh, wait. fuck.

I’ve now gotten all my Kodachrome back. The last package arrived while I was away at linux.conf.au 2011 in Brisbane.

It is certainly the end of an era, and the last of my shots will go up on flickr.

Data Storage miniconf for linux.conf.au 2011

Posted on by
Reply

Today I’ll be running the Data Storage Miniconf at linux.conf.au 2011. See the Tuesday Schedule on the LCA Website for the up to date schedule for today (the one in the badges probably out of date).

We’ve got some great talks today, so be sure to catch them. There’s also plenty of opportunity and time for discussion.

Monday linux.conf.au 2011 plan

Posted on by
Reply

It’s currently my plan to really try and make it to the following sessions:

The middle of the day will probably become “Stewart goes and panics over talks” kinda time.

Should be an awesome day.

Data Storage miniconf Lightning Talk CFP

Posted on by
Reply

Going to linux.conf.au ?

Use storage, have tales?

Admin storage system, have stories?

Hack on a storage system, have software to promote?

We want your Lightning Talk!

Databases, file systems, cloud storage, network storage, my-insane-mythtv-storage all welcome!

Send me email if you’d like to present (stewart at flamingspork dot com).

Tuesday, from 4:15pm at linux.conf.au

No implicit commit (on the road to transactional DDL)

Posted on by
2

A long time ago, in a time that can only serve to make some feel old and others older, MySQL didn’t support transactions. Each statement was executed as it went, there was no ROLLBACK (or COMMIT or crash recovery etc). Then there were transactions. Other RDBMSs implement auto_commit functionality, but for MySQL users, we think of it as the magic compatibility mode that (mostly) makes applications written for MyISAM magically work on InnoDB (okay, and making “you should use transactions” a really easy consulting gig :)

I’m currently working on finishing up a patch that removes the implicit COMMIT from DDL operations in Drizzle. Instead, you get an error message saying that Transactional DDL is not currently supported. I see a future where we have one of two situations (possibly depending on the storage engine): support DDL within normal transactions, DDL only transactions (cannot mix with DML). The latter (DDL only transactions) I see as the option for InnoDB/HailDB.

Is your Storage Engine buggy or the database server?

Posted on by
1

If your storage engine returns an error from rnd_init (or doStartTableScan as it’s named in Drizzle) and does not save this error and return it in any subsequent calls to rnd_next, your engine is buggy. Namely it is buggy in that a) an error may not be reported back to the user and b) everything may explode horribly when rnd_next is called after rnd_init returned an error.

Unless it is running on MariaDB 5.2 or (soon, when the patch hits the tree) Drizzle.

Monty (Widenius, not Taylor) wrote a patch for MariaDB based on my bug report that addressed that problem. It uses the compiler feature to throw a warning if the result of a function isn’t checked to make sure that all places that call rnd_init are checking for an error from the engine.

Today I (finally) pulled that into Drizzle as well.

So… if your engine does the logical thing and goes “oh look, this method returns an error… I’ll return my error” it will exhibit bugs in MySQL but not MariaDB 5.2 or Drizzle (when patch hits).

Which is buggy, the server or the engine?

The MySQL bug number is 54166, filed in June 2010.