For UPDATEs involving a single table, the server call to handler::direct_update_rows() is used to correctly set the count for the number of updated rows in the UPDATE statement.
However, for UPDATEs involving multi-tables, the server does not call handler::direct_update_rows(). This patch adds support to correctly report the number of updated rows to the client by setting
multi_update::updated and multi_update::found in handler::rnd_end().
* Fixes of bugs from ASAN warnings, part one
* MQC as static library, with nifty counter for global map and mutex
* Switch clang to 16
* link messageqcpp to execplan
Part 1:
As part of MCOL-3776 to address synchronization issue while accessing
the fTimeZone member of the Func class, mutex locks were added to the
accessor and mutator methods. However, this slows down processing
of TIMESTAMP columns in PrimProc significantly as all threads across
all concurrently running queries would serialize on the mutex. This
is because PrimProc only has a single global object for the functor
class (class derived from Func in utils/funcexp/functor.h) for a given
function name. To fix this problem:
(1) We remove the fTimeZone as a member of the Func derived classes
(hence removing the mutexes) and instead use the fOperationType
member of the FunctionColumn class to propagate the timezone values
down to the individual functor processing functions such as
FunctionColumn::getStrVal(), FunctionColumn::getIntVal(), etc.
(2) To achieve (1), a timezone member is added to the
execplan::CalpontSystemCatalog::ColType class.
Part 2:
Several functors in the Funcexp code call dataconvert::gmtSecToMySQLTime()
and dataconvert::mySQLTimeToGmtSec() functions for conversion between seconds
since unix epoch and broken-down representation. These functions in turn call
the C library function localtime_r() which currently has a known bug of holding
a global lock via a call to __tz_convert. This significantly reduces performance
in multi-threaded applications where multiple threads concurrently call
localtime_r(). More details on the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=16145
This bug in localtime_r() caused processing of the Functors in PrimProc to
slowdown significantly since a query execution causes Functors code to be
processed in a multi-threaded manner.
As a fix, we remove the calls to localtime_r() from gmtSecToMySQLTime()
and mySQLTimeToGmtSec() by performing the timezone-to-offset conversion
(done in dataconvert::timeZoneToOffset()) during the execution plan
creation in the plugin. Note that localtime_r() is only called when the
time_zone system variable is set to "SYSTEM".
This fix also required changing the timezone type from a std::string to
a long across the system.
* MCOL-4769 Do not replay INSERTs and LDIs on the replica nodes when
the write cache is enabled.
* MCOL-4769 If a table is created with the write cache disabled
(i.e. when columnstore_cache_inserts=OFF), make it accessible when
the cache feature is enabled (columnstore_cache_inserts=ON).
flag to ha_mcs_impl_start_bulk_insert.
An earlier commit to fix LDI under replication changed the call in
ha_mcs_cache::start_bulk_insert for a non-insert command from
parent::start_bulk_insert_from_cache to parent::start_bulk_insert.
This commit reverts that change for INSERT...SELECT operation.
Mutate the optimizer flags for prepared statements in:
1. ha_mcs::open
2. ha_mcs::discover_check_version
This is done to ensure the optimizer flags are disabled before
JOIN::prepare() is called during "PREPARE stmt FROM ...".
into the columnstore table, and not into the cache.
LDI performed on a master, comes in as a SQLCOM_END sql_command
on the slave, when binlog_format != STATEMENT. If the cache already
had some records, we were earlier flushing the cache for the LDI
on the slave. This patch detects whether we are in the slave
thread or not, if so, then we don't do a cache flush if
sql_command = SQLCOM_END.
The change for MCOL-4264 erroneously added the "lock_type" member
to cal_connection_info, which is shared between multiple tables.
So some tables that were opened for write erroneously identified
themselves as read only.
Moving the member to ha_mcs instead.
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
when starting bulk insert. This will invoke cpimport for
the query instead of batch inserts mode. This is intentional
as batch inserts currently have an edge case mentioned in
MCOL-4037 that needs to be fixed.
For queries of the form:
insert into cache1 select * from cache1;
We had a crash in the second call to get_status_and_flush_cache
due to cache->table being 0. This happened because for one of the
two ha_mcs_cache instances involved in this query, the call to
ha_mcs_cache::open was not setting cache_handler->file->lock.status_param.
The assignment to status_param was earlier protected by an if condition.
Solution is to remove that if condition in ha_mcs_cache::open.
For certain queries, such as:
update cs1 set i = 41 where i = 42 or (i is null and 42 is null);
the SELECT_LEX.where does not contain the required where conditions.
Server sends the where conditions in the call to cond_push(), so
we are storing them in a handler data member, condStack, and later
push them down to getSelectPlan() for UPDATES/DELETEs.
Several changes have happened in MariaDB 10.5, most notably:
* Information Schema table definitions have changed
* More things use LEX_CSTRING
This fixes all the compile issues
