Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.17
-
Fix Version/s: 10.0.18
-
Component/s: Data Definition - Alter Table
-
Labels:
Description
For instance:
create table t1 (a char(16)) engine=myisam;
insert into t1 values('Hello World!');
create table t2 engine=connect file_name='e:/truc/foo.txt' as select * from t1;
freezes the server (DEBUG version) with:
Open(a+b) error 2 on e:/truc/foo.txt: No such file or directory Assertion failed: 0, file .\protocol.cc, line 522 This application has requested the Runtime to terminate it in an unusual way.
However, doing:
create table t2 (a char(16)) engine=connect file_name='e:/truc/foo.txt';
insert into t2 select * from t1;
Just issue the expected message "Open error on e:/truc/foo.txt..."
Indeed the directory 'truc' does not exist on the disk E.
This may not be specific to the CONNECT engine. It seems that when the storage engine function write_row returns in error with rc= HA_ERR_INTERNAL_ERROR, the error return is handled correctly by MariaDB but in and only in the case of "CREATE TABLE ... AS SELECT ..." at the very end of the process, when the function Protocol::end_statement is called, the thd->get_stmt_da()->status() call returns an invalid value.
Things are almost worst when using a RELEASE server because the DBUG_ASSERT not being executed, no error message is displayed but the table is silently not created.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Fixed by suppressing the resetting code.
However, the issue is that this code was added because without it an assertion was raised in some cases. Unfortunately I can't remember what were these cases. Therefore fixing it in this case will perhaps make a new crash happening on another cases.
Once more, this demonstrate the very bad use of assertion in case where a proper error message should be provided.
It's a bug in the connect engine. That's what's happening:
better not to reset thd status in the engine.