1
0
mirror of https://github.com/mariadb-corporation/mariadb-columnstore-engine.git synced 2025-07-29 08:21:15 +03:00
Commit Graph

244 Commits

Author SHA1 Message Date
664bb924c4 skip all tests with LOAD DATA in case of tests via Maxscale 2025-04-16 03:22:38 +03:00
3ed2a7e298 Fix mcs170_session_functions_maxscale test 2025-04-16 03:17:17 +03:00
d5c8b98162 Merge pull request #3508 from mariadb-corporation/MCOL-5976-disable-warnings
disable warings in tests
2025-04-16 03:03:56 +03:00
ebbe067a79 Merge pull request #3509 from mariadb-corporation/MCOL-5978-remove_show_charset_vars
Remove SHOW VARIABLES LIKE 'character_set%' from the mcs228 test
2025-04-16 03:03:23 +03:00
8528fb2888 disable timestamp tests because of MCOL-5961 2025-04-16 03:08:24 +04:00
1fddc0c41c Remove SHOW VARIABLES LIKE 'character_set%' from the mcs228 test 2025-04-16 02:01:32 +03:00
e9a9d2165f disable warings in tests 2025-04-16 01:22:31 +03:00
b696e71caa preserve access rights and owner for data file in the cpimport test 2025-04-15 20:22:07 +04:00
00f04c0442 ignore stderr from 'yes' 2025-04-15 20:22:07 +04:00
67667d0a75 use to find data files 2025-04-15 20:22:07 +04:00
ef4780193b Fix test mcs7130_regression_bug3935 2025-04-15 20:21:31 +04:00
368ba3cdf7 Fix deprication warnings in the MTR with select * from .. into 2025-04-15 20:21:31 +04:00
8c8e3ab842 Fix deprication warnings in the MTR with select * from .. into 2025-04-15 20:21:31 +04:00
6a712dc0ad MCOL-5932: fix heap buffer overflow with minimal revert of MCOL-5776 breaking change (#3445) 2025-04-15 14:46:25 +01:00
c294c64bb0 chore(tests) lowercase database name due different distro settings 2025-04-11 19:10:37 +04:00
c618fa284d fix(PrimProc): MCOL-5394 JSON_ARRAYAGG in MCS works differently than in InnoDB 2025-04-11 15:21:07 +02:00
4bea7e59a0 feat(PrimProc): MCOL-5852 disk-based GROUP_CONCAT & JSON_ARRAYAGG
* move GROUP_CONCAT/JSON_ARRAYAGG storage to the RowGroup from
  the RowAggregation*
* internal data structures (de)serialization
* get rid of a specialized classes for processing JSON_ARRAYAGG
* move the memory accounting to disk-based aggregation classes
* allow aggregation generations to be used for queries with
  GROUP_CONCAT/JSON_ARRAYAGG
* Remove the thread id from the error message as it interferes with the mtr
2025-04-11 15:21:07 +02:00
fe0e67e8a1 MCOL-4607 add tests 2025-04-10 19:54:26 +04:00
3e20a3d566 MCOL-5890: DROP TABLE IF EXISTS should not generate errors for non existing tables 2025-04-08 20:30:01 +04:00
a6ab9bd615 fix(funcexp): MCOL-5386 Bitwise aggregation functions do not work with wide decimals (internal error) (#3485) 2025-04-08 16:47:47 +01:00
b8c0b74f2b fix(funexp): MCOL-4622 Implicit FLOAT->INT and DOUBLE->INT conversion is not like in InnoDB (#3480) 2025-04-04 21:28:16 +01:00
72480e512c MCOL-5922 add more datatypes for test 2025-04-02 19:54:47 +04:00
a329f4d428 Fix(MCOL-4607): SEC_TO_TIME(wideDecimal) returns 0 in DECIMAL context (#3474) 2025-03-31 15:05:07 +01:00
1bcf63a436 Fix(MCOL-4611): mod loses precision on huge narrow decimal (#3473) 2025-03-31 14:59:40 +01:00
8ca8119f36 fix(TNS): fix for duplicate DISTINCT output 2025-03-27 22:12:48 +00:00
90b4322470 feat(): propagated changes into SLTPoolAllocator and friends 2025-03-27 22:12:48 +00:00
2d69b49ba0 fix(utils): MCOL-4605 handle negative decimals in FROM_UNIXTIME (#3466) 2025-03-27 22:11:16 +00:00
1fdeb740c9 MCOL-5992: fix NULLIF if first param is NULL 2025-03-28 00:03:32 +04:00
3b2f9f5344 fix(plugin): MCOL-4942 No-table-SELECT now can return empty set (#3413)
The query like "SELECT 1 WHERE 1=0" was returning a row despite
unsatisfiable condition in WHERE. Now it returns an empty set.
2025-03-05 07:35:00 +00:00
e37d621a12 fix(MCOL-5842): Fix JSON_OBJECT's handling of empty strings
JSON_OBJECT() (and probably some other JSON functions) now properly
handle empty strings in their arguments - JSON_OBJECT used to return
NULL, now it returns empty string.
2025-02-28 17:17:16 +04:00
6e539b8336 fix(MCOL-5889): Improper handle of DOUBLE result type with DECIMAL arguments
Sometimes server assigns DOUBLE type for arithmetic operations over
DECIMAL arguments. In this rare case width of result was incorrectly
adjusted and it triggered an assertion.

Now width of result gets adjusted only if result type is also DECIMAL.
2025-02-12 18:41:55 +04:00
d7cfa15d2a fix(client): MCOL-5587: Add quick-max-column-width for maridb clients.
This changeset enables quick (mariadb -q) mode when columnstore is
installed. Quick mode precludes client CLI program from storing too
much data in memory, preventing out of memory conditions.
Add quick-max-column-width=0 to prevent extra garbage dashes in output.
2024-12-22 16:59:13 +04:00
60dc7550f1 fix(group by, having): MCOL-5776: GROUP BY/HAVING closer to server's (#3371)
This patch introduces an internal aggregate operator SELECT_SOME that
is automatically added to columns that are not in GROUP BY. It
"computes" some plausible value of the column (actually, last one
passed).

Along the way it fixes incorrect handling of HAVING being transferred
into WHERE, window function handling and a bit of other inconsistencies.
2024-12-20 19:11:47 +00:00
073f0b7f41 fix(MTR tests): Fixes autopilot MTR tests (#3368) (#3370)
Fixes in UBSAN related commit introduced more server-compatible
behavior that differ fom our old behavior. Thus, old tests broke and
their results had to be changed. This is what this patch does.
2024-12-13 15:48:37 +00:00
39a976c39a fix(ubsan): MCOL-5844 - iron out UBSAN reports
The most important fix here is the fix of possible buffer overrun in
DATEFORMAT() function. A "%W" format, repeated enough times, would
overflow the 256-bytes buffer for result. Now we use ostringstream to
construct result and we are safe.

Changes in date/time projection functions made me fix difference between
us and server behavior. The new, better behavior is reflected in changes
in tests' results.

Also, there was incorrect logic in TRUNCATE() and ROUND() functions in
computing the decimal "shift."
2024-12-10 20:30:58 +04:00
28bf654d85 Fix tests' results to match new diagnostics 2024-11-29 21:17:54 +04:00
11136b3545 fix(PrimProc): MCOL-5651 Add a workaround to avoid choosing an incorrect TupleHashJoinStep as a joiner [stable-23.10] (#3331)
* fix(PrimProc): MCOL-5651 Add a workaround to avoid choosing an incorrect TupleHashJoinStep as a joiner
2024-11-08 12:51:25 +00:00
ca6c35abdd fix(dbcon) MCOL-5812 server crash related to stored functions
Using the stored function's return value as an argument
for another function was handled incorrectly, leading
to a server crash.
2024-11-05 20:33:41 +04:00
ddbdb97071 chore(tests): canonize tests after server MDEV-19052
chore(tests): canonize hex(-1) after some server fixes
chore(tools) update fullmtr manual runner
chore(tests): canonize hex values for negative
2024-09-05 20:34:23 +03:00
539db054b3 MCOL-5779: use encoding to check alter table alter column statement correctly 2024-08-30 17:54:56 +04:00
cd626ac8a0 fix(): MCOL-5587: revert quick mode due the interactive console bug (#3255) 2024-07-30 13:40:49 +01:00
7f0c281518 fix(client): MCOL-5587: enable quick mode for predictable performance (#3240) (#3243)
This changeset enables quick (mariadb -q) mode when columnstore is
installed. Quick mode precludes client CLI program from storing too
much data in memory, preventing out of memory conditions.
2024-07-11 19:05:36 +01:00
db4cb1d657 MCOL-4234 and MCOL 5772 cherry-picked into [stable 23.10] (#3226)
* MCOL-4234: improve GROUP BY and ORDER BY interaction (#3194)

This patch fixes the problem in MCOL-4234 and also generally improves
behavior of GROUP BY.

It does so by introducing a "dummy" aggregate and by wrapping columns
into it. This allows for columns that are not in GROUP BY to be used
more freely, for example, in SELECT * FROM tbl GROUP BY col - all
columns that are not "col" will be wrapped into an aggregate and query
will proceed to execution.

The dummy aggregate itself does nothing more than remember last value
passed into it.

There also an additional error message that tries to explain what types
of expressions can be wrapped into an aggregate.

* MCOL-5772: incorrect ORDER BY ordering for a columns not in GROUP BY (#3214)

When ORDER BY column is not in GROUP BY, is not an aggregate and there
is a SELECT column that is also not an aggregate, there was a problem:
ordering happened on the SELECTed column, not ORDERed one.

This patch fixes that particular problem and also performs some tidying
around newly added aggregate.

---------

Co-authored-by: Leonid Fedorov <79837786+mariadb-LeonidFedorov@users.noreply.github.com>
2024-06-28 00:31:53 +04:00
9f4231f87f MCOL-5708 Calculate precision and scale for constant decimal. (#3227)
This patch calculates precision and scale for constant decimal
value for SUM aggregation function.
2024-06-28 00:31:03 +04:00
88e3af4ba5 fix(plugin): MCOL-5236 Take Item from Ref_Item for group by list (#3162) (#3163)
Co-authored-by: Leonid Fedorov <79837786+mariadb-LeonidFedorov@users.noreply.github.com>
2024-06-27 17:25:57 +04:00
54331e1231 MCOL-4480: TEXT type added for alter table add column (#3221) 2024-06-27 17:22:41 +04:00
1b31fd3bdb fix(plugin) MCOL-5699: throw error for unimplemented INTERSECT and EXCEPT (#3219) 2024-06-27 14:20:23 +04:00
6c6fa7d5a4 MCOL-5328: PCRE based regexp regexp_substr regexp_instr regexp_replace [stable-23.10] (#3215)
* MCOL-5328: PCRE based regexp regexp_substr regexp_instr regexp_replace

* Add qa test for MCOL-5328

---------

Co-authored-by: Susil Behera <susil.behera@mariadb.com>
2024-06-27 14:20:08 +04:00
2cd8f716c1 Fix MCOL-5035, a difference in INSERT and UPDATE behavior
The UPDATE statement wrote NULL when the column set is DATETIME and
value is '0000-00-00 00:00:00'. The problem was inside WriteEngine's
handling of UPDATE statements and this is where heart of change is.

Other changes are related to some obsolete data structures in DML/DDL
handling that just hanging around there, doing nothing.
2024-06-27 13:07:49 +03:00
cce0f6ab0c fix(cgroups)!: Containers memory limits for CI (#3108) (#3209)
Limit test containers by memory, fix cgroup path inside the containers by introducing new ugly setting name 

---------

Co-authored-by: drrtuy <roman.nozdrin@mariadb.com>
Co-authored-by: Roman Nozdrin <rnozdrin@mariadb.com>
2024-06-20 10:48:20 +01:00