[MCOL-1079] mcsapi getTableLock not failing Created: 2017-12-05 Updated: 2017-12-06 Resolved: 2017-12-06 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | None |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Andrew Hutchings (Inactive) | Assignee: | David Thompson (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Sprint: | 2017-24 | ||||||||
| Description |
|
I believe getTableLock is not failing if the table is already locked which can cause a lot of problems. We check for message failure but this message doesn't normally fail, instead it sends ownership details of the current lock holder. mcsapi is throwing this away and assuming we have the lock which is dangerous. |
| Comments |
| Comment by Andrew Hutchings (Inactive) [ 2017-12-05 ] |
|
For QA: There is a test in the API's regression suite. But you can trigger this by using the MariaDB command line to start a transaction and insert into t1 and whilst that transaction is being held open execute basic_bulk_insert. |
| Comment by David Thompson (Inactive) [ 2017-12-06 ] |
|
verified regression test and manual test with python that error is reported when dml lock is in place. |