[MCOL-80] EXTRACT() function returned assertion error Created: 2016-05-24  Updated: 2016-09-09  Resolved: 2016-09-07

Status: Closed
Project: MariaDB ColumnStore
Component/s: ExeMgr
Affects Version/s: None
Fix Version/s: 1.0.3

Type: Bug Priority: Minor
Reporter: Daniel Lee (Inactive) Assignee: David Hall (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-10309 COALESCE(12345678900) makes a column ... Closed
relates to MDEV-10317 EXCTACT(MINUTE_MICROSECOND) truncates... Closed
Sprint: 1.0.2-1, 1.0.2-2, 1.0.3

 Description   

Build tested:

InfiniDB> getcalpontsoft
getcalpontsoftwareinfo Mon May 23 19:40:49 2016

Name : infinidb-platform Relocations: (not relocatable)
Version : 5.0 Vendor: MariaDB, Inc.
Release : 0 Build Date: Sun 15 May 2016 07:24:29 PM CDT
Install Date: Mon 16 May 2016 05:21:51 PM CDT Build Host: srvbuilder

ColumnStore returns:

MariaDB [mytest]> select cidx, CDATE, EXTRACT(HOUR_MICROSECOND FROM CDATE) from datatypetestm order by cidx;
ERROR 1815 (HY000): Internal error: st: 0 TupleBPS::receiveMultiPrimitiveMessages() caught an exception: IDB-2035: An internal error occurred. Check the error log file & contact support.

MariaDB [mytest]> select cidx, CDATE, EXTRACT(MINUTE_MICROSECOND FROM CDATE) from datatypetestm order by cidx;
ERROR 1815 (HY000): Internal error: st: 0 TupleBPS::receiveMultiPrimitiveMessages() caught an exception: IDB-2035: An internal error occurred. Check the error log file & contact support.

err.log

May 23 19:42:23 columnStore Calpont[33411]: 23.815677 |0|0|0| E 00 CAL0000: batchprimitiveprocessor-jl.cpp@660: assertion 'in.length() > offset' failed
May 23 19:42:25 columnStore Calpont[33411]: 25.341703 |0|0|0| E 00 CAL0000: batchprimitiveprocessor-jl.cpp@660: assertion 'in.length() > offset' failed

crit.log

May 23 19:42:23 columnStore PrimProc[33351]: 23.813868 |0|0|0| C 28 CAL0000: supported: #012
May 23 19:42:23 columnStore joblist[33411]: 23.815767 |911420|0|0| C 05 CAL0000: st: 0 TupleBPS::receiveMultiPrimitiveMessages() caught an exception: IDB-2035: An internal error occurred. Check the error log file & contact support.#012
May 23 19:42:25 columnStore PrimProc[33351]: 25.340987 |0|0|0| C 28 CAL0000: upported: #012
May 23 19:42:25 columnStore joblist[33411]: 25.341828 |911420|0|0| C 05 CAL0000: st: 0 TupleBPS::receiveMultiPrimitiveMessages() caught an exception: IDB-2035: An internal error occurred. Check the error log file & contact support.#012 

MariaDB [tpch1]> select cidx, CDATE, EXTRACT(HOUR_MICROSECOND FROM CDATE) from DataTypeTestm order by cidx;;
 
+------+------------+--------------------------------------+
 
| cidx | CDATE      | EXTRACT(HOUR_MICROSECOND FROM CDATE) |
 
+------+------------+--------------------------------------+
 
|    1 | 1997-01-01 |                                    0 |
 
|    2 | 1997-01-01 |                                    0 |
 
|    3 | 1997-01-02 |                                    0 |
 
|    4 | 1997-01-03 |                                    0 |
 
|    5 | 1997-01-04 |                                    0 |
 
|    6 | 2009-12-28 |                                    0 |
 
|    7 | 2009-12-29 |                                    0 |
 
|    8 | 2009-12-30 |                                    0 |
 
|    9 | 2009-12-31 |                                    0 |
 
|   10 | 2009-12-31 |                                    0 |
 
|   11 | 2009-12-31 |                                    0 |
 
+------+------------+--------------------------------------+
 
11 rows in set (0.00 sec)



 Comments   
Comment by Dipti Joshi (Inactive) [ 2016-05-31 ]

Daniel Lee Is this still happening ? Your autopilot results that you shared on May 24th was showing that EXTRACT function is working.

Comment by Dipti Joshi (Inactive) [ 2016-06-18 ]

dleeyh Is this duplicate of MCOL-99 and MCOL-149 ?

Comment by David Hall (Inactive) [ 2016-06-28 ]

Added code for all interval types.

This exposed an issue of interval_minute_microsecond intervals returning the wrong values. The reason is that in item_timefunc.cc, fix_length_and_dec() sets max length to 11:

case INTERVAL_MINUTE_MICROSECOND: max_length=11; date_value=0; break;

later on, it sets the field type to int32_t, which has a max value of 2,147,483,647 (10 digits). When EXTRACT puts a minute+second+microsecond together, we also get 10 digits. For 59 minutes, 56 seconds, and 0 microseconds, EXTRACT creates 5956000000 (10 digits).

When mysqld creates the field to hold the result in item_func.cc line 526, it creates an int32_t because it checks max_length against the constant MY_INT32_NUM_DECIMAL_DIGITS, which is defined as 11:

switch (result_type()) {
case INT_RESULT:
if (max_char_length() > MY_INT32_NUM_DECIMAL_DIGITS)
field= new (mem_root)
Field_longlong(max_char_length(), maybe_null, name,
unsigned_flag);
else
field= new (mem_root)
Field_long(max_char_length(), maybe_null, name,
unsigned_flag);
break;

Now when we try to put 5956000000 into the field, it notices that 5956000000 > max(int) and saturates, returning the wrong value.

Comment by David Hall (Inactive) [ 2016-06-29 ]

The problem with INTERVAL_MINUTE_MICROSECOND is caused by the bug reported in MDEV-10309

Comment by Alexander Barkov [ 2016-07-01 ]

A script demonstrating the problem with EXTRACT:

SET timestamp=UNIX_TIMESTAMP('2001-01-01 23:59:59.999999');
 
SELECT EXTRACT(MINUTE_MICROSECOND FROM NOW(6));
 
DROP TABLE IF EXISTS t1;
 
CREATE TABLE t1 AS SELECT EXTRACT(MINUTE_MICROSECOND FROM NOW(6));
 
SELECT * FROM t1;
 
SHOW CREATE TABLE t1;

SELECT EXTRACT() correctly returns 5959999999

+-----------------------------------------+
 
| EXTRACT(MINUTE_MICROSECOND FROM NOW(6)) |
 
+-----------------------------------------+
 
|                              5959999999 |
 
+-----------------------------------------+

The value stored in the table is erroneously truncated to 2147483647

+-----------------------------------------+
 
| EXTRACT(MINUTE_MICROSECOND FROM NOW(6)) |
 
+-----------------------------------------+
 
|                              2147483647 |
 
+-----------------------------------------+

And the created column data type is wrong:

+-------+-----------------------------------------------------------------------------------------------------------------------------+
 
| Table | Create Table                                                                                                                |
 
+-------+-----------------------------------------------------------------------------------------------------------------------------+
 
| t1    | CREATE TABLE `t1` (
 
  `EXTRACT(MINUTE_MICROSECOND FROM NOW(6))` int(11) DEFAULT NULL
 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
 
+-------+-----------------------------------------------------------------------------------------------------------------------------+

The expected data type is bigint.

Comment by David Hall (Inactive) [ 2016-09-07 ]

Fixed by MDEV-10309. Tested 09/06/2016

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