[MCOL-4758] Cluster crashes when LONGTEXT or LONGBLOB fields are involved in a query Created: 2021-06-14  Updated: 2021-07-06  Resolved: 2021-07-06

Status: Closed
Project: MariaDB ColumnStore
Component/s: None
Affects Version/s: 1.2.0
Fix Version/s: 6.1.1

Type: Bug Priority: Blocker
Reporter: Gregory Dorman (Inactive) Assignee: Daniel Lee (Inactive)
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Issue split
split from MCOL-3879 ExeMgr crash on select - SELECT TABLE... Closed
Sprint: 2021-8, 2021-9

 Description   

Columnstore claims support for 2GB long LONGTEXT and LONGBLOB, to be in line with InnoDB.

However, internal implementation is insufficiently strong. On one hand, it allocates the buffer for the maximum row size, but then it is unable to handle the data because the buffer length in the code is integer, and cannot exceed 2GB.

It has been noted that our main competitors - RedShift and SnowFlake limit LONTEXT and LONGBLOB to just 16MB.

For 6.1.1 the resolution will be:

  • reduce the limit to 16MB
  • Change the documentation accordingly - jacob.moorman

After the change, the crash may still be present if the table would have over 100 LONGTEXT fields, an unrelaistic scenario.

The original ticket - MCOL-3879 will, in due time, protect from that as well.



 Comments   
Comment by David Hall (Inactive) [ 2021-06-16 ]

This fix affects DDL (CREATE and ALTER). Existing tables will not be modified and won't work. Of course, there shouldn't be any existing tables that show this problem because they don't work at all.

Comment by David Hall (Inactive) [ 2021-06-23 ]

I made changes and added mtr test

Comment by Gagan Goel (Inactive) [ 2021-07-05 ]

For QA: To verify the fix, refer to David's comment from MCOL-3879 at 2021-04-21 14:22. ExeMgr should no longer crash with that test case and the query should return expected results.

Comment by Daniel Lee (Inactive) [ 2021-07-06 ]

Build verified: 6.1.1 (#2727)

Reproduced the issue in 5.6.1 and verified the fix in 6.1.1.

Generated at Thu Feb 08 02:52:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.