[MCOL-1186] INSERT..SELECT Fails "Error Code: 1815. Internal error" Created: 2018-01-30  Updated: 2022-11-05  Resolved: 2022-11-05

Status: Closed
Project: MariaDB ColumnStore
Component/s: N/A
Affects Version/s: 1.1.1
Fix Version/s: Icebox

Type: Task Priority: Minor
Reporter: Aziz Vahora Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None

Attachments: File columnstoreSupportReport.columnstore-1.tar.gz    

 Description   

use test;

create table test1_cs (id int,cName varchar(50)) engine=columnstore;

– This statement works as expected
insert into test1_cs(id,cName) values(1,'Testing1');

– Thist statement does not work.
insert into test1_cs (id,cName)
select 2,'Testing2';

– Results in following error
/*
Error Code: 1815. Internal error: load failed. The detailed error information is listed in err.log.
*/

Is this a bug or do I need to enable some flag?

We are not able to transfer data from one columnstore table to another and worst yet from staging innodb table to columnstore table. Currently we have written a work around to use CPIMPORT tool. This is certainly slowing down our pipeline and testing.

Here is getsoftwareinfo
Tue Jan 30 22:05:04 2018

Name : mariadb-columnstore-platform Relocations: (not relocatable)
Version : 1.1.1 Vendor: MariaDB Corporation Ab
Release : 1 Build Date: Thu 02 Nov 2017 11:28:34 PM UTC
Install Date: Tue 14 Nov 2017 11:18:21 PM UTC Build Host: ip-172-30-0-72.us-west-2.compute.internal
Group : Applications/Databases Source RPM: mariadb-columnstore-platform-1.1.1-1.src.rpm
Size : 10817092 License: Copyright (c) 2016 MariaDB Corporation Ab., all rights reserved; redistributable under the terms of the GPL, see the file COPYING for details.
Signature : (none)
URL : http://mariadb.org
Summary : MariaDB-Columnstore software



 Comments   
Comment by David Thompson (Inactive) [ 2018-01-30 ]

Hi, first you might want to upgrade to the GA version 1.1.2 but aside from that, there is likely an underlying error reported in the logs under /var/log/mariadb/columnstore, e.g. in err.log. Can you review that, if it doesn't make sense you can send us directly a columnstore support file: https://mariadb.com/kb/en/library/system-troubleshooting-mariadb-columnstore/#mariadb-columnstore-support-report-tool

Without more details, it might be you are running low on /tmp space if cpimport is working ok for the same table. When you run insert select with autocommit on it internally buffers the data in tmp.

Comment by Aziz Vahora [ 2018-01-30 ]

Hello David,

Here is the only line in our err.log file
"Jan 30 04:00:18 sj2-mariadbpoc01 oamcpp[47943]: 18.140852 |0|0|0| E 08 CAL0000: OamCache::checkReload shows state for pm1 as DEGRADED"
columnstoreSupportReport.columnstore-1.tar.gz
/tmp folder is located on the drive with 3.5TB of space.

cpimport into the table works perfectly fine even with loading 10's of thousands of rows.

attached file for the support tool output.

Comment by Aziz Vahora [ 2018-01-30 ]

FYI,
I have restarted my columnStore and pm1 is now ACTIVE.

Comment by David Thompson (Inactive) [ 2018-01-30 ]

The degraded state is because it can't find the pid for mysqld:
getsysteminfo Tue Jan 30 23:20:09 2018

System columnstore-1

System and Module statuses

Component Status Last Status Change
------------ -------------------------- ------------------------
System ACTIVE Tue Jan 23 19:53:58 2018

Module pm1 DEGRADED Wed Jan 17 17:32:53 2018

MariaDB ColumnStore Process statuses

Process Module Status Last Status Change Process ID
------------------ ------ --------------- ------------------------ ----------
ProcessMonitor pm1 ACTIVE Fri Jan 12 20:27:58 2018 33478
ProcessManager pm1 ACTIVE Fri Jan 12 20:28:04 2018 33573
DBRMControllerNode pm1 ACTIVE Fri Jan 12 20:28:12 2018 34140
ServerMonitor pm1 ACTIVE Fri Jan 12 20:28:14 2018 34160
DBRMWorkerNode pm1 ACTIVE Fri Jan 12 20:28:14 2018 34178
DecomSvr pm1 ACTIVE Fri Jan 12 20:28:18 2018 34244
PrimProc pm1 ACTIVE Fri Jan 12 20:28:20 2018 34262
ExeMgr pm1 ACTIVE Tue Jan 23 19:53:56 2018 41789
WriteEngineServer pm1 ACTIVE Fri Jan 12 20:28:28 2018 34471
DDLProc pm1 ACTIVE Fri Jan 12 20:28:32 2018 34506
DMLProc pm1 ACTIVE Fri Jan 12 20:28:36 2018 34542
mysqld pm1 MAN_OFFLINE Wed Jan 24 17:23:10 2018

But obviously it is still running since you were able to run queries. We've seen this before but not yet sure of the cause but is benign.

Comment by David Thompson (Inactive) [ 2018-01-30 ]

On my 1.1.2 instance the specific test case above works just fine. Does this still reproduce after the restart?

Comment by Aziz Vahora [ 2018-01-30 ]

Wow that is weird.
It is working fine now.
Could that be the cause that system was in degraded status due to mysqld process not recognized?
Funny, it was working fine since the last time I upgraded the system.

Comment by David Thompson (Inactive) [ 2018-01-30 ]

Possibly, will need to investigate further but good to know that a restart cleared it.

Comment by David Thompson (Inactive) [ 2018-01-31 ]

Do you recall if you started having problems right after Jan 24th 17:23 or more recently. It looks like myslqd was restarted then and for whatever reason no pid file was created.

Comment by Todd Stoffel (Inactive) [ 2022-11-05 ]

Item is out of date. Closing due to inactivity. If you feel this was done in error please open a new ticket.

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