Problem:
When processing cross-engine queries like:
update cstab1 set a=100 where a not in (select a from innotab1 where a=11);
delete from innotab1 where a not in (select a from cstab1 where a=1);
the ColumnStore plugin erroneously executed the whole query inside
ColumnStore.
Fix:
- Adding a new member cal_connection_info::lock_type and setting it
inside ha_mcs_impl_external_lock() to the value passed in the parameter
"lock_type".
- Adding a method cal_connection_info::isReadOnly() to test
if the last table lock made in ha_mcs_impl_external_lock()
for done for reading.
- Adding a new condition checking cal_connection_info::isReadOnly() inside
ha_mcs_impl_rnd_init(). If the current table was locked last time for reading,
then doUpdateDelete() should not be executed.
During data retrieval, we were type casting a field type to what we thought was the correct type. Often it was not. Since we're calling virtual functions on *f, there's no need to type cast in most cases. This was a relic from days gone by.
from server/columnstore_cache.
Commit message:
Fixed bug in free locks that caused rows in cache to not be properly flushed
Fixed by doing adding external_lock(F_UNLCK) in free_locks.
I also moved unlock of cache_handler to be after changing lock type of
cached tables to ensure that no one can use cached table while this is
happening (as cache table is locked with write lock).
I also fixed a wrong mutex order bug in ha_cache::flush_insert_cache()
Other things:
- Addded share::cached_rows to track inserted rows. This is only used
for asserts to check the number of rows in the cache.
- Fixed wrong mysql_file_chsize() in case of repair
We are creating a new read-only system variable, columnstore_cache_inserts,
to enable/disable the cache. When this variable is set at server start up,
any table created with engine=columnstore will also create the corresponding
cache table in Aria engine for performing inserts.
It is important to note that a ColumnStore table created with this
option unset should not be queried when the server is restarted with
the option set, as this will most likely result in query failures.
2. Set 100k as the batch size when flushing records into ColumnStore, i.e.,
a flush of 1M records will be performed in 10 batches, each being 100k.
3. For INSERT ... SELECT on the cache, use the default insertion method of cpimport.
from server/columnstore_cache
Commit message:
Fixed crashed bug on simple insert
Other things:
- Added test from columnstore team
- Fixed two reported bugs from columnstore team
- Call free_locks as part of start_trans() instead of get_status()
to ensure that we have locks both for cached table and cache table
before we try to free any.
- Store pointers to lock->get_status and lock->update_status for the
cached table. Was needed by ha_tina in flush_insert_cache to make
new insert rows visible for the SELECT that caused the flush
from server/columnstore_cache.
Commit message:
Fixed bug in cache:
- The THR_LOCK org_lock must be stored in a shared structure so that all
instances of a table can use it. Fixed by adding a ha_cache_share object
that keeps track of this one.
- Fixed wrong test in get_status_and_flush_cache to detect in insert command
- Fixed in get_status_and_flush_cache that we always free the insert lock
if we don't need it.
.cnf file overwriting plugin-maturity must be lexicographically
after mariadb-enterprise.cnf
also set the maturity correctly without relying on supermodule doing it
