If a cleanup schema command is executed and the schema contains histogram tables, the operation "succeeds" (but not really). One of the transactions performing the cleanup commands is left in the aborting state, for example:
(1,0,13) 0,12159 281474976710669 ABORTING PT2 willRollback tmAborted readOnly
create schema sch1;
set schema sch1;
create table t1(a int not null primary key);
create table t2 (a int not null primary key,
b int not null unique,
c int not null references t1(a),
e char(2) check (e > 'a'),
f largeint generated by default as identity not null);
create index t2 on t2(b);
insert into t1 values (1), (2), (3), (4), (5), (6), (7), (8);
update statistics for table t1 on every column;
cleanup schema sch1;
After recovering from the transaction issue (restarting Trafodion), the following objects still exist in hbase:
After removing objects from hbase, restarted sqlci:
get schemas - schema sch1 does not exist.
create schema sch1 - succeeded
create table t1 - succeeded
create table t2 - failed *** ERROR Object TRAFODION.SEABASE.T2 already exists in Trafodion.
Table t2 is accessible - so metadata entries were not removed.
Looking a bit into the cleanup code - part of removing an object, tries to delete rows from the histograms table. So if we are removing a histogram table, probably should not be deleting from it at the same time. May also want to wait until all the other tables in the schema are removed before delete histogram tables (or delete the histogram tables first).
Prototyped a change that:
As part of cleanup schema, cleaned up all the non histogram tables first then cleaned up the histogram tables.
As part of dropping a histogram table, did not call dropSeabaseStats.
This seemed to fix the problem.
May want to handle failures from delete histogram rows better. Also, if someone tries to cleanup one histogram table, perhaps all should be dropped.