Centos 6.5

This is most likely caused by schema out of sync caused by some crash or assert. In such a case, there is no bug, but the error is disconcerting.

The fix here should be to handle this situation gracefully with a warnining instead of an erorr since most users would use this syntax to have robust scripts that don't fail.

Not sure on the best way to recreate the scenario though..

Currently, when this error occurs, the system does not drop the table from the front end (i.e., MariaDB). That is, the .frm files is not deleted. In this case, a warning isn't all that useful, as the table isn't dropped. A subsequent create will fail.

Perhaps a better, though more complex solution, is to drop the table from the front-end and issue a warning that the table didn't exist in the engine. At this point, all vestiges of the table will have been removed and the user will get what they expect.

In a test environment, this bug can be reproduced by deleting all the table information from the calpont system catalog – calpontsys, Doing so won't delete the data files, so it could clutter up your data directory. A clean out should be done after working on it this way.

By reading the comments, I don't know what solution was implemented to fix the issue.

This is the comment from github: Throw warning when table doesn't exist in columnstore so drop table if exists can still remove the front end table.

Build tested: 1.0.5-1

mcsadmin> getsoft
getsoftwareinfo Tue Nov 22 10:13:49 2016

Name : mariadb-columnstore-platform
Version : 1.0.5
Release : 1
Architecture: x86_64
Install Date: Tue 22 Nov 2016 10:10:12 AM CST
Group : Applications/Databases
Size : 9990112
License : Copyright (c) 2016 MariaDB Corporation Ab., all rights reserved; redistributable under the terms of the GPL, see the file COPYING for details.
Signature : (none)
Source RPM : mariadb-columnstore-platform-1.0.5-1.src.rpm
Build Date : Mon 21 Nov 2016 07:29:37 PM CST

Functionally, it is working now, but the warning is incorrect, misleading, and unnecessary.

Thoughts?

-------
MariaDB [mytest]> show tables;
------------------

------------------

------------------
1 row in set (0.00 sec)

MariaDB [mytest]> create table t1 (c1 int) engine=columnstore comment='schema sync only';
Query OK, 0 rows affected (0.00 sec)

MariaDB [mytest]> show tables;
------------------

------------------

------------------
2 rows in set (0.00 sec)

MariaDB [mytest]> select * from t1;
ERROR 1815 (HY000): Internal error: IDB-2006: 'mytest.t1' does not exist in Columnstore.
MariaDB [mytest]> show tables;
------------------

------------------

------------------
2 rows in set (0.00 sec)

MariaDB [mytest]> drop table if exists t1;
Query OK, 0 rows affected, 1 warning (0.02 sec)

MariaDB [mytest]> show warnings;
-------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------
1 row in set (0.00 sec)

MariaDB [mytest]> show tables;
------------------

------------------

------------------
1 row in set (0.00 sec)

I am reopening the ticket, since the warning instructs the user to restart DMLProc when DMLProc is not the issue.

In this case, Columnstore table exists in the front end but not the back end. There is no data files for the requested table so file deletion is not even needed. There should not be an error deleting such files. When starting DMLProc, it would clean up orphan files if there is any, and I think that's the reason for the instruction.

I believe the original case was the opposite of your case where the columnstore data files exist but calpontsys is out of sync. See David Halls comment from 10/3. What is reported is a slightly different maninfestation of the same overall issue that should also be fixed but maybe better filed as a new bug.

Re-assigned to Ben, wasn't my ticket

The situation is that the table no longer exist in the engine, but still exist in the front end schema. When dropping the table, the engine would report missing table and the drop table statement will not do anything and the table schema still exist in the front end. When trying to create the table with the same name, the create table statement would failed.

If a table is missing from the system catalog, and the data files still exist, the files will be orphan files and there is no way to know what they are. In the case where errors occurred during dropping a table, restarting DMLProc will clean up the orphan files.

Mr. Hall's comment on 10/4 was to simulate the table-missing-from-engine situation by deleting the table from the system catalog.

I believe the fix is working as intended, and the warning is not needed. Of course, if the existing behavior is expected, then we can close the ticket.

Thanks.

Build verified: 1.0.5-1

mcsadmin> getsoft
getsoftwareinfo Wed Nov 23 14:43:49 2016

Name : mariadb-columnstore-platform
Version : 1.0.5
Release : 1
Architecture: x86_64
Install Date: Wed 23 Nov 2016 02:34:05 PM CST
Group : Applications/Databases
Size : 9990112
License : Copyright (c) 2016 MariaDB Corporation Ab., all rights reserved; redistributable under the terms of the GPL, see the file COPYING for details.
Signature : (none)
Source RPM : mariadb-columnstore-platform-1.0.5-1.src.rpm
Build Date : Wed 23 Nov 2016 08:55:49 AM CST

Restested with the latest build since the last build had an issue.

The group decided the existing behavior is good. Closing it.