List:Maria Storage Engine« Previous MessageNext Message »
From:Guilhem Bichot Date:February 4 2009 5:01pm
Subject:bitmap->changed=0 without mutex?
View as plain text  
Hello Monty,

In revision sp1r-monty@stripped/narttu.mysql.fi-20080529153333-17560
you did this change to _ma_flush_table_files():

      if (share->data_file_type == BLOCK_RECORD)
      {
-      if(_ma_bitmap_flush(share) ||
-         flush_pagecache_blocks(share->pagecache, &info->dfile,
-                                flush_type_for_data))
-        goto err;
+      if (flush_type_for_data != FLUSH_IGNORE_CHANGED)
+      {
+        if (_ma_bitmap_flush(share))
+          error= 1;
+      }
+      else
+        info->s->bitmap.changed= 0;
+      if (flush_pagecache_blocks(share->pagecache, &info->dfile,
+                                 flush_type_for_data))
+        error= 1;
      }

with comment "Optimization: - Don't flush io_cache or bitmap if we are 
using FLUSH_IGNORE_CHANGED".

I wonder, isn't it a problem to do
info->s->bitmap.changed= 0;
without having bitmap->bitmap_lock?

The only caller of this function with FLUSH_IGNORE_CHANGED for the data 
file is maria_delete_all_rows() which takes an exclusive lock on the 
table (and will continue doing so in future Maria versions otherwise it 
cannot my_chsize() the files, as this removes any old rows so kills 
versioning).
But there could be a concurrent checkpoint doing _ma_bitmap_flush_all(), 
I wonder if there can be an issue there.

I propose to add a bitmap mutex lock/unlock around the setting, to feel 
safe.

-- 
Mr. Guilhem Bichot <guilhem@stripped>
Sun Microsystems / MySQL, Lead Software Engineer
Bordeaux, France
www.sun.com / www.mysql.com
Thread
bitmap->changed=0 without mutex?Guilhem Bichot4 Feb
  • re: bitmap->changed=0 without mutex?Michael Widenius4 Feb