I noticed that this discussion thread has drifted to touch the Innobase source
>I've creates database and fills it with tables and datas
>(all ok), then drops database and re-creates it. When I've
>trying to re-create tables and fills it I've get SIGSEGV at:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 8201 (runnable)]
> 0x8153c20 in row_create_table_for_mysql
> at row0mysql.c:796
> 796 ut_a(err ==
>As I understand, the problem is in innobase (because when
>I'm drops database all its tables must be dropped too and
>all data space must be freed).
>Also, ut_a() must generate some reasonable error message
>without trapping server...
DROP DATABASE does not work yet for Innobase, presumably because
MySQL only deletes the files in the database directory, and does not
call DROP TABLE for each of the tables. Since Innobase tables are
stored in its own tablespace, they are preserved. Then you get the
assertion failure (which generates the seg fault) when you try to
recreate the tables.
We have to fix DROP DATABASE, and also add a better error message
(than assertion failure) in case Innobase internal data
dictionary and MySQL .frm files are not in 'sync'.
>As I can see (without going deep through innobase's sources
>and ha_innobase.cc) the trouble was at rem0cmp.c
>(cmp_whole_field()). Because I've uses koi8_ru charset as
>default, innobase uses DATA_VARMYSQL for varchar fields (and
>DATA_VARCHAR for fields with charset latin1) which is not
>listed in case() switch (found DATA_MYSQL only). Looking in
>innobase_mysql_cmp() I've see that it supports for both
>fixed and variable-length strings, so I've just added
>DATA_VARMYSQL together with DATA_MYYSQL to the case in
>Patch file is attached.
Yes, I forgot to add the type DATA_VARMYSQL (meaning non-latin1
character string) to cmp_whole_field in rem0cmp.c. I have
added the fix to the source repository of MySQL 3.23.34.
In principle, a non-latin1 version of Innobase should work,
but it has not been tested. Paul should know it best.
>PS: Innobase handler is too slow comparing with
When you say that Innobase handler is slow, are you running it
in the autocommit mode? Then it has to flush the log to disk after each
insert or update you do, which means max 100 operations per second.
Try using non-autocommit mode or, set in my.cnf innobase_flush_trx_at_commit