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
