1. In TupleUnion::writeNull(), add the missing switch case for
wide decimal with 16bytes column width.
2. MCOL-5432 Disable complete/partial pushdown of UNION operation
if the query involves an ORDER BY or a LIMIT clause, until
MCOL-5222 is fixed. Also add MTR test cases for this.
When a UNION operation involving DECIMAL datatypes with scale and digits
before the decimal exceeds the currently supported maximum precision
of 38, we throw an error to the user:
"MCS-2060: Union operation exceeds maximum DECIMAL precision of 38".
This is until MCOL-5417 is implemented where ColumnStore will have
full parity with MariaDB server in terms of maximum supported DECIMAL
precision and scale of 65 and 38 digits respectively.
* Add MTR_SUITE_LIST
* Typo
* Add data download
* Install tar and lz4
* Change the way MTR_SUITE_LIST is set up
* Use bash for MTR_SUITE_LIST
* Another one
* Fix reference results for full MTR develop, disable broken JSON test and tests with 10GB database
* Fix timestamps and truncate cos
* Fix some more references
* Fix dokcerhub step for custom build
* One more fix for dockerhub step on custom build
* Fix tests for regr functions with truncate
* Full mtr set on nghtly + MTR_FULL_SET flag
* One more fix for dockerhub
* Fix MTR_FULL_SET
* Testing MTR_FULL_SET
* sorted_result in tests + fix typo
* Truncate even more
* Typo
* truncate 2 more tests
* Disable regr_* functions tests
* fix setup mtr step
* correct settings for table creation
* Put setup for tests into drone
* Fix for debian based distros
* More truncates
* Disable the rest
---------
Co-authored-by: Leonid Fedorov <leonid.fedorov@mariadb.com>
CSC default ctor was private b/c it must not allow to use CSC outside thread cache.
However there are some places in the plugin code that need a standalone syscat that
is cleaned up leaving the scope. The decision is to make the restriction mentioned
organizational rather than syntactical.
This reverts commit f4e3022fbdecc25a22ae6eaf072e462aa6695f35.
The commit apparently caused MCOL-5318 and MCOL-5319 which involve the
internal ColumnStore batch insert mechanism passing through the SQL
layer. The code block involved in this change is a predicate checking
for the HWM extent in WriteEngineServer at the end of the batch insert.
This is done in WE_DMLCommandProc::processBatchInsertHwm(). The original
predicate check in this function for the HWM extent is restored until
further investigation.
These seem to have all fallen out of a recent Boost update to 1.81 which
dropped some internal includes. All of these uses within columnstore
relied on these transitive includes, so explicitly include what we need
to fix build.
Signed-off-by: Sam James <sam@gentoo.org>
In the implementation of MCOL-5021, an assert was added in
`WE_DMLCommandProc::processBatchInsertHwm()` that assumed the
`WriteEngine::TableMetaData` cache is uniform across the cluster.
However, this assumption is incorrect.
This bug caused undefined behaviour in ColumnStore resulting in bugs
such as MCOL-5367. In MCOL-5367, in a multi-node ColumnStore cluster,
an INSERT ... SELECT in a transaction with system variable
`columnstore_use_import_for_batchinsert=OFF/ON` did not show inserted
records when a SELECT query was issued. Assuming a 3-node cluster setup,
DMLProc only sends a given batch of records to be inserted to one of the
3 nodes, and not all nodes. As a result, the `WriteEngine::TableMetaData`
cache is only populated for that one node and is not uniform across the
cluster, causing the assert to fail.
As a fix, we simply remove this assert as it is redundant and should not
have been added in the first place.
Analyze needs to be completed differently than a normal query. In server, when an ANALYZE is seen, it calls init_scan() immediatly followed by end_scan(). This leaves the sqlfrontendsession (ExeMgr) in a state where it expects to return rows. This patch fixes end_scan to clean this up via reads and writes to get everything back in synch.
ANALYZE should display the number of rows to be displayed if the query were run normally. We have that information available, but no way to return it. A modification to server side to ask for that in the handler is required.
This patch also includes a beautification of sqlfrontsessionthread.cpp since it looked bad. The important change is at line 774
if (!swallowRows)
which short circuits the actual return of data
