Mcol 4652 support for wide decimals in cpimport communication with dbrm #1840

mariadb-SergeyZefirov · 2021-04-02T12:20:55Z

No description provided.

mariadb-SergeyZefirov · 2021-04-02T12:27:52Z

writeengine/bulk/we_brmreporter.cpp

@@ -413,7 +414,7 @@ int BRMReporter::openRptFile( )
        return rc;
    }

-    fRptFile << "#CP:   startLBID max min seqnum type colwidth newExtent"    << std::endl;
+    fRptFile << "#CP:   startLBID seqnum type colwidth max min newExtent"    << std::endl;


Max and min values should be after type and colWidth - these two determine types used.

writeengine/bulk/we_brmreporter.cpp

writeengine/splitter/we_brmupdater.cpp

tntnatbry · 2021-04-07T10:12:35Z

writeengine/splitter/we_brmupdater.cpp

+
+	    if (datatypes::isWideDecimalType(cpInfoMerge.type, cpInfoMerge.colWidth))
+	    {
+                datatypes::SystemCatalog::TypeAttributesStd tyAttr(cpInfoMerge.colWidth, 0, 38);


Instead of using the hard-coded value 38 here, we should use datatypes::INT128MAXPRECISION

I don't see the change requested here, please fix.

writeengine/splitter/we_brmupdater.cpp

tntnatbry · 2021-04-07T11:06:59Z

mtr/basic/t/mcol4652-cpimport-sets-wide-decimals-ranges.test

+
+LOAD DATA LOCAL infile './suite/columnstore/std_data/1m_customer.tbl' INTO TABLE customer FIELDS TERMINATED BY '|';
+SELECT logical_block_start, min_value, max_value FROM information_schema.columnstore_extents WHERE width = 16;
+DROP DATABASE mcol4652;


IMO, we should not add this test case into mtr/basic. This is because wide decimals is still an unreleased feature, with this patch, we are fixing an issue for a feature which is still in progress.

I think mtr/future should be the right place to add this test case. The mtr/future/mcol641-insert.test has some LDI statements already, so this could be a good place to add this test. In mcol641-insert.test, we can append to the end the following:

--echo # --echo # MCOL-4652 Support for wide decimals in cpimport communication with dbrm --echo # --disable_warnings DROP DATABASE IF EXISTS mcol4652; --enable_warnings ... (remaining test case)

The select statement also should be more specific like so:

select c.table_schema, c.table_name, c.column_name, e.min_value, e.max_value from information_schema.columnstore_extents e, information_schema.columnstore_columns c where c.table_schema='mcol4652' and c.column_name='c_custkey' and c.object_id=e.object_id;

In general I agree. But I would like you to consider other tests in basic suite. Here's a grep of the results directory:

mcs211_idbExtentId_function.result:SELECT idbExtentId(col1) FROM t1 LIMIT 1;
mcs211_idbExtentId_function.result:idbExtentId(col1)
mcs211_idbExtentId_function.result-234496
...
mcs212_idbExtentMax_function.result:SELECT idbExtentMax(col1) FROM t1 LIMIT 1;
mcs212_idbExtentMax_function.result:idbExtentMax(col1)
mcs212_idbExtentMax_function.result-32767
...
cs213_idbExtentMin_function.result:SELECT idbExtentMin(col1) FROM t1 LIMIT 1;
mcs213_idbExtentMin_function.result:idbExtentMin(col1)
mcs213_idbExtentMin_function.result-0
...
mcs214_idbExtentRelativeRid_function.result:SELECT idbExtentRelativeRid(col1) FROM t1 WHERE col1=2 LIMIT 1;
mcs214_idbExtentRelativeRid_function.result:idbExtentRelativeRid(col1)
mcs214_idbExtentRelativeRid_function.result-47898

and bunch of MCOL-2044 tests I produced (guilty).

All these tests will fail if any of the tests fail to properly clean their intermediate results, including inability to end (server has crashed during the test).

So in this concrete test I am doing what everyone else was and is doing and assuming what everyone else was and is assuming. Even in producing MCOL-2044 tests I did the same: there are tests that depend on every other test to be perfectly executed so mine's can do that also.

What's more, their logic is such that it is not possible to formulate them otherwise.

I am not resolving this part of conversation and am waiting for your opinion.

The grep output from the .result files for the tests in the basic suite you shared above (mcs211, mcs212, mcs213, mcs214) looks correct to me. Here, the queries are of the form SELECT idbExtentId(col1) FROM t1 LIMIT 1;. This query is not dependent on other tests since it is specific to the current test: it is executed on the current schema, table t1 and column col1.

On the other hand, the query in the .test file you are adding in this PR: SELECT logical_block_start, min_value, max_value FROM information_schema.columnstore_extents WHERE width = 16;

This is a metadata query and filtering only on the width=16. There are following issues with this:

If mtr is run with the --force option, and during the run, another test fails abruptly and does not clean up, this above query can fail.

If mtr is run with the --extern option, and there are columnstore tables in the existing mariadb server installation, this query will again fail if in the existing database installation, there already exists columnstore tables with column widths = 16.

Unfortunately the test cases added in MCOL-2044 also suffer from these issues and would need to be fixed.

Please, look at mcs211_idbExtentId_function, both test and result files.

In a result file the output of extent ID function is hardcoded to 234496 - this is first extent ID assigned on a clear installation of columnstore.

Here's relevant part:

SELECT idbExtentId(col1) FROM t1 LIMIT 1;
idbExtentId(col1)
234496

It is not possible to fix this test - it is meant to be executed in clean environment and there's nothing we (you, me, anyone else in our team) can do about it.

As long as we have at least one test that needs complete cleanup of all other tests, we can add other tests that depends on that condition.

I don't agree on this. mcs211_idbExtentId_function is testing a specific function that needs a clean installation of the database; there is no other way to make this test pass (as we need a hard-coded extent ID).

While here, as well as in the MCOL-2044 tests, we don't need to have a clean installation since we can ensure that the test will certainly pass whether we have a clean installation or not, if we make the SELECT statement more specific for this test.

Okay. I moved tests to "future" part of MCS/mtr tests. But there is a problem.

I've loaded data as in test and found this:

MariaDB [mcol4652]> SELECT e.min_value, e.max_value -> FROM information_schema.columnstore_extents e, information_schema.columnstore_columns c -> WHERE c.table_schema='mcol4652' -> AND c.column_name='c_custkey' -> AND c.object_id=e.object_id; Empty set (0.055 sec)

Trying to debug it further, I've found that even simple joins stopped to work:

MariaDB [mcol4652]> SELECT e.min_value, e.max_value FROM information_schema.columnstore_extents e, information_schema.columnstore_columns c WHERE c.table_schema='mcol4652' AND c.object_id=e.object_id; Empty set (0.037 sec)

The filtering on characters strings also stops working:

ariaDB [mcol4652]> SELECT * FROM information_schema.columnstore_columns c; +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ | TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | OBJECT_ID | DICTIONARY_OBJECT_ID | LIST_OBJECT_ID | TREE_OBJECT_ID | DATA_TYPE | COLUMN_LENGTH | COLUMN_POSITION | COLUMN_DEFAULT | IS_NULLABLE | NUMERIC_PRECISION | NUMERIC_SCALE | IS_AUTOINCREMENT | COMPRESSION_TYPE | +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ | mcol4652 | customer | c_custkey | 3099 | NULL | NULL | NULL | decimal | 16 | 0 | NULL | 0 | 38 | 0 | 1 | Snappy | | mcol4652 | customer | c_name | 3100 | 3107 | NULL | NULL | varchar | 25 | 1 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_address | 3101 | 3108 | NULL | NULL | varchar | 40 | 2 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_nationkey | 3102 | NULL | NULL | NULL | int | 4 | 3 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_phone | 3103 | 3109 | NULL | NULL | char | 15 | 4 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_acctbal | 3104 | NULL | NULL | NULL | decimal | 8 | 5 | NULL | 0 | 12 | 2 | 1 | Snappy | | mcol4652 | customer | c_mktsegment | 3105 | 3110 | NULL | NULL | char | 10 | 6 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_comment | 3106 | 3111 | NULL | NULL | varchar | 117 | 7 | NULL | 0 | 10 | 0 | 1 | Snappy | +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ 8 rows in set (0.010 sec) MariaDB [mcol4652]> SELECT * FROM information_schema.columnstore_columns c WHERE c.table_schema = 'mcol4652'; Empty set (0.009 sec)

This warrants further investigation outside of this PR.

Okay, @drrtuy said it may be just infeasible to have proper tests working with the information_schema tables.

I test back to the simplest one.

@mariadb-SergeyZefirov I am unable to reproduce the issues you mentioned above. Below is the output from my machine based on the up-to-date server 10.6 branch and develop engine branch (you can ignore the NULL values for min/max for now):

MariaDB [(none)]> DROP DATABASE IF EXISTS mcol4652; Query OK, 0 rows affected, 1 warning (0.001 sec) MariaDB [(none)]> CREATE DATABASE mcol4652; Query OK, 1 row affected (0.001 sec) MariaDB [(none)]> USE mcol4652; Database changed MariaDB [mcol4652]> create table customer ( -> c_custkey decimal(38), -> c_name varchar (25), -> c_address varchar (40), -> c_nationkey int, -> c_phone char (15), -> c_acctbal decimal(12,2), -> c_mktsegment char (10), -> c_comment varchar (117) -> ) engine=columnstore; Query OK, 0 rows affected (0.435 sec) MariaDB [mcol4652]> SELECT * FROM information_schema.columnstore_columns c; +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ | TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | OBJECT_ID | DICTIONARY_OBJECT_ID | LIST_OBJECT_ID | TREE_OBJECT_ID | DATA_TYPE | COLUMN_LENGTH | COLUMN_POSITION | COLUMN_DEFAULT | IS_NULLABLE | NUMERIC_PRECISION | NUMERIC_SCALE | IS_AUTOINCREMENT | COMPRESSION_TYPE | +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ | mcol4652 | customer | c_custkey | 3001 | NULL | NULL | NULL | decimal | 16 | 0 | NULL | 0 | 38 | 0 | 1 | Snappy | | mcol4652 | customer | c_name | 3002 | 3009 | NULL | NULL | varchar | 25 | 1 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_address | 3003 | 3010 | NULL | NULL | varchar | 40 | 2 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_nationkey | 3004 | NULL | NULL | NULL | int | 4 | 3 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_phone | 3005 | 3011 | NULL | NULL | char | 15 | 4 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_acctbal | 3006 | NULL | NULL | NULL | decimal | 8 | 5 | NULL | 0 | 12 | 2 | 1 | Snappy | | mcol4652 | customer | c_mktsegment | 3007 | 3012 | NULL | NULL | char | 10 | 6 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_comment | 3008 | 3013 | NULL | NULL | varchar | 117 | 7 | NULL | 0 | 10 | 0 | 1 | Snappy | +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ 8 rows in set (0.102 sec) MariaDB [mcol4652]> SELECT * FROM information_schema.columnstore_columns c WHERE c.table_schema = 'mcol4652'; +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ | TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | OBJECT_ID | DICTIONARY_OBJECT_ID | LIST_OBJECT_ID | TREE_OBJECT_ID | DATA_TYPE | COLUMN_LENGTH | COLUMN_POSITION | COLUMN_DEFAULT | IS_NULLABLE | NUMERIC_PRECISION | NUMERIC_SCALE | IS_AUTOINCREMENT | COMPRESSION_TYPE | +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ | mcol4652 | customer | c_custkey | 3001 | NULL | NULL | NULL | decimal | 16 | 0 | NULL | 0 | 38 | 0 | 1 | Snappy | | mcol4652 | customer | c_name | 3002 | 3009 | NULL | NULL | varchar | 25 | 1 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_address | 3003 | 3010 | NULL | NULL | varchar | 40 | 2 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_nationkey | 3004 | NULL | NULL | NULL | int | 4 | 3 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_phone | 3005 | 3011 | NULL | NULL | char | 15 | 4 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_acctbal | 3006 | NULL | NULL | NULL | decimal | 8 | 5 | NULL | 0 | 12 | 2 | 1 | Snappy | | mcol4652 | customer | c_mktsegment | 3007 | 3012 | NULL | NULL | char | 10 | 6 | NULL | 0 | 10 | 0 | 1 | Snappy | | mcol4652 | customer | c_comment | 3008 | 3013 | NULL | NULL | varchar | 117 | 7 | NULL | 0 | 10 | 0 | 1 | Snappy | +--------------+------------+--------------+-----------+----------------------+----------------+----------------+-----------+---------------+-----------------+----------------+-------------+-------------------+---------------+------------------+------------------+ 8 rows in set (0.017 sec) MariaDB [mcol4652]> SELECT e.min_value, e.max_value -> FROM information_schema.columnstore_extents e, information_schema.columnstore_columns c -> WHERE c.table_schema='mcol4652' -> AND c.column_name='c_custkey' -> AND c.object_id=e.object_id; +-----------+-----------+ | min_value | max_value | +-----------+-----------+ | NULL | NULL | +-----------+-----------+ 1 row in set (0.077 sec)

tntnatbry · 2021-04-07T11:10:57Z

The source branch name MCOL-4652-Support-for-wide-decimals-in-cpimport-communication-with-DBRM looks too long, Something like MCOL-4652-develop should suffice.

mariadb-SergeyZefirov

The source branch name MCOL-4652-Support-for-wide-decimals-in-cpimport-communication-with-DBRM looks too long, Something like MCOL-4652-develop should suffice.

I strongly prefer it that way. In case of long branch names like that I (and others, I hope) have at least an indication what this branch is about and should I or someone else even consider looking at it.

Also, Github does not cross-link PR and branches' names with our JIRA tickets and long branch names can save a click and/or minute or so of distraction.

writeengine/splitter/we_brmupdater.cpp

tntnatbry · 2021-04-27T12:05:44Z

mysql-test/columnstore/future/mcol4652-cpimport-sets-wide-decimals-ranges.result

+c_mktsegment char (10),
+c_comment varchar (117)
+) engine=columnstore;
+LOAD DATA LOCAL infile './suite/columnstore/std_data/1m_customer.tbl' INTO TABLE customer FIELDS TERMINATED BY '|';


The .result file is not in sync with the .test file here.

tntnatbry · 2021-04-27T12:06:11Z

mysql-test/columnstore/future/mcol4652-cpimport-sets-wide-decimals-ranges.test

+
+--replace_result $MTR_SUITE_DIR MTR_SUITE_DIR
+--eval LOAD DATA LOCAL infile '$MTR_SUITE_DIR/../std_data/100Krows.dat' INTO TABLE t1 FIELDS TERMINATED BY '|'
+SELECT e.min_value, e.max_value FROM information_schema.columnstore_extents e, information_schema.columnstore_columns c;


Please fix this SELECT statement as we have discussed earlier.

tntnatbry · 2021-04-27T12:08:39Z

writeengine/splitter/we_brmupdater.cpp

+
+	    if (datatypes::isWideDecimalType(cpInfoMerge.type, cpInfoMerge.colWidth))
+	    {
+                datatypes::SystemCatalog::TypeAttributesStd tyAttr(cpInfoMerge.colWidth, 0, 38);


I don't see the change requested here, please fix.

tntnatbry · 2021-04-27T12:12:39Z

@mariadb-SergeyZefirov I have added additional comments to the PR. Once the comments are addressed, please squash all commits into a single commit, and also please fix the original commit message.

Test to verify correctness Support for wide decimals in reporting Filter in test results Proper SQL syntax in test Test uses wide decimals now Possible fix for clearly incorrect string-to-wide-int conversion Result for a test Rename file for result Less verbose output for test Fix test result case sensitivity related failure Cleanup for MCOL-4652 test case Update submodule to develop version Remove erroneous colWidth field read operation Test, without results for now Remove tabs Correct test result Fixed both test and result The most correct test result Revert back to simpler SELECT clause Move tests in new proper location Load data from suite-relative location

mariadb-SergeyZefirov · 2021-04-30T14:02:27Z

I have to say that I am extremely unhappy with how this PR goes.

The concerns are as follows.

Moving test in "future" test suite

This breaks use of CI. Neither reviewers nor me cannot see how new tests are faring on different platforms.

The case of columnstore/basic.unsigned_joins told me it is quite possible to have different execution on different platforms.

This brings me to my second concern

More specific SELECT statement still returns empty row set

I still have problems with this specific select returning empty set of rows.

My current version is rebased over pretty recent develop branch, git log includes commits from Apr 27 (3741032 for most recent).

My reviewer was unable to reproduce the problem with his setup and I consistently reproduce it with mine's. This means I have some divergent execution on my hands here and I cannot use our CI to find out what and where.

There are other concerns there, but these two above are main ones.

@tntnatbry please, address them.

…erent platforms

mariadb-SergeyZefirov · 2021-04-30T16:08:04Z

@tntnatbry please, address them.

I think I should explain better.

I see your arguments and requests for changes as, well, some sort of higher decisions which prevail over mine's. You certainly have more experience working with MariaDB and with source code up there.

But I also clearly see I cannot successfully address them in foreseeable future. Because I have divergent execution and it blocks my work. Instead work on the concrete PR problem I work on something else.

So here I am asking you to provide me with more workable way to have this functionality in the main tree.

mariadb-SergeyZefirov · 2021-04-30T17:41:26Z

The (semifailing) query in question is this:

SELECT
    c.table_schema, c.table_name, c.column_name,
    e.min_value, e.max_value
FROM
information_schema.columnstore_extents e,
information_schema.columnstore_columns c
WHERE
         c.table_schema='mcol4652'
AND c.column_name='c_custkey'
AND c.object_id=e.object_id;

tntnatbry · 2021-05-03T08:06:06Z

@mariadb-SergeyZefirov I have confirmed along with @abarkov, we both are getting the following output on the SELECT statement that is returning an empty set for you:

MariaDB [(none)]> CREATE DATABASE mcol4652;
Query OK, 1 row affected (0.001 sec)

MariaDB [(none)]> USE mcol4652;
Database changed

MariaDB [mcol4652]> create table customer (
    ->         c_custkey decimal(38),
    ->         c_name varchar (25),
    ->         c_address varchar (40),
    ->         c_nationkey int,
    ->         c_phone char (15),
    ->         c_acctbal decimal(12,2),
    ->         c_mktsegment char (10),
    ->         c_comment varchar (117)
    -> ) engine=columnstore;
Query OK, 0 rows affected (0.772 sec)

MariaDB [mcol4652]> SELECT
    ->     c.table_schema, c.table_name, c.column_name,
    ->     e.min_value, e.max_value
    -> FROM
    -> information_schema.columnstore_extents e,
    -> information_schema.columnstore_columns c
    -> WHERE
    ->          c.table_schema='mcol4652'
    -> AND c.column_name='c_custkey'
    -> AND c.object_id=e.object_id;
+--------------+------------+-------------+-----------+-----------+
| table_schema | table_name | column_name | min_value | max_value |
+--------------+------------+-------------+-----------+-----------+
| mcol4652     | customer   | c_custkey   |      NULL |      NULL |
+--------------+------------+-------------+-----------+-----------+
1 row in set (0.032 sec)

Can you try running this sequence of statements on a clean develop build (without your patch), although I don't think the patch changes are related to queries involving information_schema tables.

tntnatbry · 2021-05-03T08:23:22Z

Can you also run the following queries and post outputs here:

1.
SELECT c.object_id, c.table_schema, c.table_name, c.column_name
FROM
  information_schema.columnstore_columns c
WHERE
    c.table_schema='mcol4652' AND c.column_name='c_custkey';

2.
SELECT c.object_id, c.table_schema, c.table_name, c.column_name, e.object_id, e.min_value, e.max_value
FROM
  information_schema.columnstore_columns c
  LEFT OUTER JOIN
  information_schema.columnstore_extents e
  ON c.object_id=e.object_id
WHERE
    c.table_schema='mcol4652' AND c.column_name='c_custkey';

3.
SELECT e.object_id, e.min_value, e.max_value
FROM
  information_schema.columnstore_extents e
WHERE
  object_id=XXX;

where XXX is the object_id from the result from the first SELECT from information_schema.columnstore_columns alone. So this split will help to understand if:

the problem is in information_schema.columnstore_columns
or the problem is in information_schema.columnstore_extents
or the problem is in JOIN between them

drrtuy · 2021-06-02T11:42:15Z

The issue has been fixed and merged in a different PR.

mariadb-SergeyZefirov force-pushed the MCOL-4652-Support-for-wide-decimals-in-cpimport-communication-with-DBRM branch from 7375c23 to 17a4328 Compare April 2, 2021 12:25

mariadb-SergeyZefirov requested a review from tntnatbry April 2, 2021 12:25

mariadb-SergeyZefirov commented Apr 2, 2021

View reviewed changes

mariadb-SergeyZefirov force-pushed the MCOL-4652-Support-for-wide-decimals-in-cpimport-communication-with-DBRM branch 2 times, most recently from a3d3f60 to 2941706 Compare April 6, 2021 11:45

tntnatbry suggested changes Apr 7, 2021

View reviewed changes

mariadb-SergeyZefirov commented Apr 9, 2021

View reviewed changes

writeengine/splitter/we_brmupdater.cpp Show resolved Hide resolved

mariadb-SergeyZefirov force-pushed the MCOL-4652-Support-for-wide-decimals-in-cpimport-communication-with-DBRM branch 3 times, most recently from 098ac1b to 9740151 Compare April 15, 2021 11:21

tntnatbry suggested changes Apr 27, 2021

View reviewed changes

mariadb-SergeyZefirov force-pushed the MCOL-4652-Support-for-wide-decimals-in-cpimport-communication-with-DBRM branch from 17054f5 to 79da1aa Compare April 29, 2021 12:19

Fix test

c91bb18

mariadb-SergeyZefirov added 2 commits April 30, 2021 17:06

Put test back into CI-accessible part to see how they will do on diff…

44ae8b5

…erent platforms

More precise select in test to get results for different platforms

f814988

Fix test in columnstore/basic

5f77d2b

drrtuy self-requested a review May 5, 2021 14:18

drrtuy closed this Jun 2, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mcol 4652 support for wide decimals in cpimport communication with dbrm #1840

Mcol 4652 support for wide decimals in cpimport communication with dbrm #1840

mariadb-SergeyZefirov commented Apr 2, 2021

mariadb-SergeyZefirov Apr 2, 2021

tntnatbry Apr 7, 2021

mariadb-SergeyZefirov Apr 9, 2021

tntnatbry Apr 27, 2021

tntnatbry Apr 7, 2021

mariadb-SergeyZefirov Apr 9, 2021

mariadb-SergeyZefirov Apr 9, 2021

tntnatbry Apr 12, 2021 •

edited

mariadb-SergeyZefirov Apr 12, 2021

tntnatbry Apr 12, 2021

mariadb-SergeyZefirov Apr 14, 2021

mariadb-SergeyZefirov Apr 14, 2021

tntnatbry Apr 16, 2021

tntnatbry commented Apr 7, 2021

mariadb-SergeyZefirov left a comment

tntnatbry Apr 27, 2021

tntnatbry Apr 27, 2021

tntnatbry Apr 27, 2021

tntnatbry commented Apr 27, 2021

mariadb-SergeyZefirov commented Apr 30, 2021

mariadb-SergeyZefirov commented Apr 30, 2021

mariadb-SergeyZefirov commented Apr 30, 2021 •

edited

tntnatbry commented May 3, 2021

tntnatbry commented May 3, 2021

drrtuy commented Jun 2, 2021

Mcol 4652 support for wide decimals in cpimport communication with dbrm #1840

Mcol 4652 support for wide decimals in cpimport communication with dbrm #1840

Conversation

mariadb-SergeyZefirov commented Apr 2, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tntnatbry Apr 12, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tntnatbry commented Apr 7, 2021

mariadb-SergeyZefirov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tntnatbry commented Apr 27, 2021

mariadb-SergeyZefirov commented Apr 30, 2021

Moving test in "future" test suite

More specific SELECT statement still returns empty row set

mariadb-SergeyZefirov commented Apr 30, 2021

mariadb-SergeyZefirov commented Apr 30, 2021 • edited

tntnatbry commented May 3, 2021

tntnatbry commented May 3, 2021

drrtuy commented Jun 2, 2021

tntnatbry Apr 12, 2021 •

edited

mariadb-SergeyZefirov commented Apr 30, 2021 •

edited