MySQL Lists: commits: bk commit into 4.1 tree (stewart:1.2483) BUG#19894

The other day I committed this bug fix. A one bit patch. It is generally decided amongst the team that nobody will ever produce a smaller patch.

ERROR: The requested URL could not be retrieved (yeah, site didn’t work when i clicked on it from RSS).

Matt uses this bit of ruby code to demonstrate that here you can’t ever not close the file handle:

File.open('something.txt') do |fd|
# Manipulate the file through 'fd'
end
# File handle is now closed

Which seems pretty cool. However, a good C++ programmer can also acheive the same (or better) things!

For example, in NDB (well, in the portability library we use inside NDB) we have a class called Guard. The constructor for Guard pthread_mutex_locks a mutex. The destructor unlocks it. So, for when you’ve got some simple mutual exclusion you need doing, you can have bits of code like this:

{
Guard g(m_config_mutex);

// other_stuff
}

Guess what, those nice little error checking bits that should just return -1 look a lot cleaner and you can never forget to unlock the mutex! You’ll see code like this in the management server (ndb_mgmd – source in storage/ndb/src/mgmsrvr/ mostly in MgmtSrvr.cpp).

In fact, you can do this with files as well (multiple ones)  and have them all closed on exit from the block. It’s all a matter of having (or writing) some good classes. I’m no Ruby expert – but I think you’d have to have more indentation to do that with two files?

I’ve been working on BUG#17928, which is all about “testBackup fails in error handling testcases” which appeared after we merged in some work to the 5.1 tree (which is okay in 5.0) that changes some things in the way that online backups are done in NDB to better support recovery in the event of various types of failures and various times in the process.

Anyway, not all systems are affected by this bug… I’m at least reproducing some of the failures on my laptop and have spent the past while in the depths of the BACKUP and NDBFS blocks trying to work out what’s going on and why we’re hitting this assert.

NDBFS is an interesting block as it’s the file system interaction for NDB – so we’re doing things that could take an arbitrary amount of time. We don’t like waiting for those sorts of things in cluster, so we go on and do other work.

For backup, we buffer up writes and send FSAPPENDREQ (File System Append Request) to NDBFS only when we have a reasonable amount of data to send. For example, for very small rows being put into the log file, no use making a write() call for each row – batch them into big chunks!

Back to the bug; I’ve got a theory[1], half a patch and some work to do tomorrow.

[1] excluding gratuitous Buffy quote