mirror of
https://github.com/MariaDB/server.git
synced 2025-01-17 20:42:30 +01:00
e25623e78a
The assertion failed in handler::ha_reset upon SELECT under READ UNCOMMITTED from table with index on virtual column. This was the debug-only failure, though the problem is mush wider: * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw bitmap. * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and sometimes all_set and tmp_set, are assigned to the pointers. * Sometimes tmp_use_all_columns is used to substitute the raw bitmap directly with all_set.bitmap * Sometimes even bitmaps are directly modified, like in TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called. The last three bullets in the list, when used together (which is mostly always) make the program flow cumbersome and impossible to follow, notwithstanding the errors they cause, like this MDEV-17556, where tmp_set pointer was assigned to read_set, write_set and vcol_set, then its bitmap was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call, and then bitmap_clear_all(&tmp_set) was applied to all this. To untangle this knot, the rule should be applied: * Never substitute bitmaps! This patch is about this. orig_*, all_set bitmaps are never substituted already. This patch changes the following function prototypes: * tmp_use_all_columns, dbug_tmp_use_all_columns to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map* * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept MY_BITMAP* instead of my_bitmap_map* These functions now will substitute read_set/write_set/vcol_set directly, and won't touch underlying bitmaps. |
||
|---|---|---|
| .. | ||
| AUTHORS | ||
| ChangeLog | ||
| CMakeLists.txt | ||
| FAQ | ||
| federatedx_io.cc | ||
| federatedx_io_mysql.cc | ||
| federatedx_io_null.cc | ||
| federatedx_probes.h | ||
| federatedx_txn.cc | ||
| ha_federatedx.cc | ||
| ha_federatedx.h | ||
| README | ||
| README.windows | ||
| TODO | ||
This is the FederatedX Storage Engine, developed as an external storage engine. NOTE: The following is only relevant if you use it for MySQL. MariaDB already comes with the latest version of FederatedX. To install, grab a copy of the mysql source code and run this: ./configure --with-mysql=/path/to/src/mysql-5.x --libdir=/usr/local/lib/mysql/ make install And then inside of MySQL: mysql> INSTALL PLUGIN federatedx SONAME 'libfederatedx_engine.so'; mysql> CREATE TABLE `d` (`a` varchar(125), b text, primary key(a)) ENGINE=FEDERATEDX CONNECTION="mysql://root@host/schema/table" or mysql> CREATE TABLE `d` (`a` varchar(125), b text, primary key(a)) ENGINE=FEDERATEDX CONNECTION="server" CHARSET=latin1; You will probably need to edit the Makefile.am in the src/ tree if you want to build on anything other then Linux (and the Makefile assumes that the server was not compiled for debug). The reason for the two possible configure lines is that libdir is dependent on where MySQL was installed. If you run the "INSTALL PLUGIN ..." and you get a file not found, check that your configured this directory correctly. For Solaris you can enable DTrace probes by adding to configure --enable-dtrace