List:Internals« Previous MessageNext Message »
From:Kristian Nielsen Date:May 14 2009 7:19am
View as plain text  
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, line 3682.")

Yes. This is a debugging help to ensure that read_set and write_set are used

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

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.
ASSERT_COLUMN_MARKED_FOR_READ questionVyacheslav Akhmechet14 May
  • Re: ASSERT_COLUMN_MARKED_FOR_READ questionKristian Nielsen14 May
  • Re: ASSERT_COLUMN_MARKED_FOR_READ questionSergei Golubchik14 May
    • Re: ASSERT_COLUMN_MARKED_FOR_READ questionVyacheslav Akhmechet15 May