Red Hat Enterprise Linux Server release 7.2 (Maipo)

Hi, is it possible for you to attach or send over seperately a support report as that will give us the info we need to triage further:
https://mariadb.com/kb/en/library/system-troubleshooting-mariadb-columnstore/#mariadb-columnstore-support-tool

You can also send this directly to me if you don't feel comfortable attaching to this jira.

Also if you can describe the symptoms a bit more that might help. Will a given query work for some time and then fail or will a given query always fail and then make the system unstable? Anything else going on around the same time when problems occur? The logs in the support report may tell us this but always good to get a human perspective.

Hi, the error was not present these days but today it happened again.

i have attached the support report, i have removed some archive logs because the file was too big for attachment.

The scenario is like this:

• We store information in 1 table per day.
• There is always a single thread executing LOAD DATA INFILE into the daily table.
• At the same time there maybe another threads doing agregation on the daily table.
• The error only shows in this daily tables.
• Table has approximately 1,800,000,000 rows at the end of the day.
• The error doesn't affect perfomarnce
• The errors only goes away if i server restart or flush cache, example:

[root@elastic103 space]# mcsmysql -D cdrdatos

MariaDB [cdrdatos]> SELECT access_point_name_NI,SUM(duration) FROM cdr20170926 GROUP BY access_point_name_NI;
ERROR 1815 (HY000): Internal error: An unexpected condition within the query caused an internal processing error within InfiniDB. Please check the log files for more details. Additional Information: error in BatchPrimitiveProces

..... +after server restart +.......

MariaDB [cdrdatos]> SELECT access_point_name_NI,SUM(duration) FROM cdr20170926 GROUP BY access_point_name_NI;
-----------------------------------+

-----------------------------------+

Any suggestion is aprecciated.

Thanks, that is definitely helpful. What i can see today is that around 12:44, exemgr crashed:
Sep 27 12:44:23 localhost joblist[652]: 23.827443 |0|0|0| C 05 CAL0000: /home/builder/mariadb-columnstore-server/mariadb-columnstore-engine/dbcon/execplan/clientrotator.cpp @ 318 Could not get a ExeMgr connection.

You can also see this by the fact it has a later start date by running mcsadmin getProcessStatus (ProcMon will restart it if it detects a crash).

I don't know if it's the cause or just a long running query but the following query never finished:
Sep 27 12:41:36 localhost ExeMgr[1055]: 36.345880 |574921|0|0| D 16 CAL0041: Start SQL statement: select served_MSISDN fono, hour(DATE_ADD(record_opening_time, INTERVAL duration SECOND)) hora, sum(losd_time_usage) t, sum(losd_datavolume_fbc_uplink + losd_datavolume_fbc_downlink) datavolume from cdrdatos.cdr20170925 where DATE_ADD(record_opening_time, INTERVAL duration SECOND) BETWEEN '2017-09-25 00:00:00' and '2017-09-25 23:59:59' and served_MSISDN regexp '^519[0-9]

$' and (uli_ci + uli_sac + uli_ecgi) in ( 10900, 10901, 10902, 10903, 10908, 10909, 62201, 10905, 10906, 10907, 20361, 20362, 20363, 20365, 20366, 20367, 57170, 57176, 57177, 62200, 62206, 62207, 130839143, 130839141, 130839142, 132152421 ) and (uli_lac + uli_tai) in (1183,1412,14121) group by served_MSISDN, hour(DATE_ADD(record_opening_time, INTERVAL duration SECOND)) order by served_MSISDN, hour(DATE_ADD(record_opening_time, INTERVAL duration SECOND)) asc limit 10; |cdrdatos|

This likely is tied in with the original errors you reported but i don't see any reported between 12.41 and 12.47. If it's ok to do on your system can you try running the above query manually and see if that triggers any error. It's possible it could be exhausting memory but you have a very beefy machine so this seems less likely.

One thing that i can say is that we have fixed some similar stability bugs in 1.0.10 and 1.0.11 so it may be worthwhile considering an upgrade to 1.0.11 first?

I reported a similar issue for the version 1.1.0.

Perhaps for a workaround, one may try replacing the SMALLINT columns with INT.

Thanks for your help!, i have many datatypes for my table like (bigint, tinyint, smallint, char, varchar) and reading your issue one guy said that it will happen with any columns not being the same, does this mean all my columns need to be integer for example?

According to LinuxJedi, all columns should have the same widths (in bytes) as the first column. Since "one cannot currently use CHANGE COLUMN to change the definition of that column," I used DROP/CREATE to change the column data type.

Guys correct me if i am wrong:
I found the commit: basically what i need to confirm from this is If i put in my first column the smallest datatype of my table the error for calculating row id will be gone?

That is a great example of thinking outside the box! However, as discussed in MCOL-1105, ADD COLUMN can only put the column at the end of the table.