Vyacheslav Akhmechet <coffeemug@stripped> writes:
> In my storage engine, when the server calls write_row, I read the
> first field of the row in order to index on this field. I do it in the
> following way:
>
> Field **field = table->field;
> long index = (*field)->val_int();
>
> It works perfectly in release mode, but in debug mode val_int
> generates ASSERT_COLUMN_MARKED_FOR_READ assertion (which is: "(!table
> || (!table->read_set || bitmap_is_set(table->read_set, field_index))),
> function val_int, file field.cc, line 3682.")
Yes. This is a debugging help to ensure that read_set and write_set are used
correctly.
Normally, the storage engine must only look at fields in the row for which the
corresponding bit in read_set is set. Otherwise it may be looking at
uninitialised/random data. In debug mode there is an assert to catch this
mistake.
However, in some cases the storage engine does need to access fields not in
read_set, for example if it has itself read extra columns into a record (like
unique constraint check), or as here, in write_row(), where a missing bit
indicates that the field is set to default value, not that it is missing.
In this case, you need to use dbug_tmp_use_all_columns() and
dbug_tmp_restore_column_map() like this:
my_bitmap_map *old_map= dbug_tmp_use_all_columns(table, table->read_set);
Field **field = table->field;
long index = (*field)->val_int();
...
dbug_tmp_restore_column_map(table->read_set, old_map);
This disables the assert for this part of the code, where the programmer is
then responsible for getting it right.
Hope this helps,
- Kristian.