redhat 7.2 Maipo
Linux s4-mariadbcs-um-01 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux

Can you check the logs on the pms as well? Alternatively you can run the columnstoreSupport utility which will bundle up everything useful?

I'd suspect you are blowing the limit for our dml transaction buffer. If you need to do a very large update like this i'd suggest either increasing the version buffer size (see last section here: https://mariadb.com/kb/en/mariadb/columnstore-batch-insert-mode) or batching your updates by date. If your data is loaded in date order (or approximiately) this will also be efficient due to partition elimination.

Hi David.

The actual update is only 85 rows on the multi-million row table.
There are no error reported on the PM's during these errors.
unfortunatley I cannot upload the logs as the server were reinstalled.
Here is the primary OAM log files that I could get.

One thing i see in the logs is using a variety of where clause filters. For partition elimination to work currently you should avoid using functions:
update schema_1.test_data_fct a, schema_1.test_data_dim_user_prf b set a.co_cde = b.co_cde where a.user_ref = b.user_ref and a.bhdb = b.bhdb and a.co_cde <> b.co_cde and b.co_cde > 0 and a.event_date >= (date_format('2017-04-01','%Y%m%d'))

would be much faster (assuming data is loaded by event_date) as:
update schema_1.test_data_fct a, schema_1.test_data_dim_user_prf b set a.co_cde = b.co_cde where a.user_ref = b.user_ref and a.bhdb = b.bhdb and a.co_cde <> b.co_cde and b.co_cde > 0 and a.event_date >= '2017-04-01'

Otherwise the system must scan the entire set of rows.

YYYY-MM-DD is the default date format for mariadb

thanks for the info.
I will be rebuilding this environment for testing in the next 2 days (hoping to have servers by then ) and will try to replicate this bug.

Please re-open if this reproduces with the proposed changes.