FROM CUSTOMER

For the first problem, I think the stored autoincrement is not going back to 0, but staying to whatever was reserved until the rollback get triggered by the error rows.

Ignore the second problem, it was a mixed of bad sorted input data and each PM reserving autoincrement blocks making them not contiguous. I came to the conclusion that importing that table to only PM1 should give me ordered autoincrement value and it did.

Patrice.

This is to be expected and this can happen with InnoDB too:

"With InnoDB, values can be reserved by a transaction; but if the transaction fails (for example, because of a ROLLBACK) the reserved value will be lost."

https://mariadb.com/kb/en/library/auto_increment/#missing-values

Other relational databases also observe this behaviour.

FROM CUSTOMER

I am not sure I understand this correctly.

I am saying that no data has been imported because the cpimport failed, however the autoincrement value is not going back to its original value. You are saying it should be lost, so it should not stay at the reserved value, which is what i am reporting.

FROM CUSTOMER

Ok i understand the wording now. lost as in 'not usable again'.

So in light of this, can I request a feature to support this syntax in columnstore :

create table t1(a int default (next value for s1),b int) engine=Columnstore;

as show in the sequence documentation :

Using Sequences in DEFAULT
MariaDB starting with 10.3.3

Starting from 10.3.3 you can use Sequences in DEFAULT

A separate feature request for this could be created but we would require several other things to be implemented first which will allow using MariaDB Server for all CSV imports instead of cpimport (which in-turn means accelerating and improving LOAD DATA INFILE). I would not expect us to be able to implement this prior to 10.5.