[MCOL-2093] cleartablelock is allowed during mcsapi transaction but it breaks with what(): Error rolling back BRM and cannot be restarted Created: 2019-01-18 Updated: 2023-10-26 Resolved: 2023-03-06 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Icebox |
| Type: | Bug | Priority: | Major |
| Reporter: | Zdravelina Sokolovska (Inactive) | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Environment: |
single server |
||
| Epic Link: | Consolidate & Redevelop All Columnstore Tools (SDK, Adapters, Backup, Restore, mcsimport) |
| Epic/Theme: | MCOL-4571 |
| Description |
|
cleartablelock is allowed during mcsapi transaction but it breaks with what(): Error rolling back BRM and cannot be restarted note: the same is not observed with cpimport as cleartablelock is rejected during cpimport activities with error" Rollback error: Unable to grab lock; Lock not found or still in use.Table lock xxx for table xx.yy is not cleared."
from CS Module
|
| Comments |
| Comment by Jens Röwekamp (Inactive) [ 2019-01-28 ] |
|
If I understand your process correctly, you This probably happens as the bulk insert fails in mcsimport, (due to the cleared lock), but during the deconstruction of mcsapi's ColumnStoreBulkInsert a second cleartablelock is executed, which couldn't succeed as the changes were already rolled back. |
| Comment by Andrew Hutchings (Inactive) [ 2019-01-28 ] |
|
I would go as far as to say this is expected behaviour. Maybe the error is not too clear but that would require an architecture change to fix. You rolled back a transaction that is currently executing and the API gets confused when it suddenly realises it has gone away. |
| Comment by Todd Stoffel (Inactive) [ 2023-03-06 ] |
|
This ticket was created prior to convergence with the server and may be obsolete. If you find this issue still exists in a modern version, please open a new ticket. |