Uploaded image for project: 'Apache Trafodion'
  1. Apache Trafodion
  2. TRAFODION-1812

cleanup schema causes transaction to hang in aborting state

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: sql-cmu
    • Labels:
      None

      Description

      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

      Test case:

      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),
      d blob,
      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;
      get tables;
      cleanup schema sch1;
      get tables;
      get schemas;

      After recovering from the transaction issue (restarting Trafodion), the following objects still exist in hbase:

      TRAFODION.SCH1.SB_HISTOGRAM_INTERVALS
      TRAFODION.SCH1.T1
      TRAFODION.SCH1.T2
      TRAFODION.SCH1.T2_651147319_7148
      TRAFODION.SCH1.T2_945247319_7148

      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[1390] 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.

        Attachments

          Activity

            People

            • Assignee:
              rmarton Roberta Marton
              Reporter:
              rmarton Roberta Marton
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: