[
https://issues.apache.org/jira/browse/TRAFODION-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15377185#comment-15377185
]
ASF GitHub Bot commented on TRAFODION-2037:
-------------------------------------------
Github user robertamarton commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/565#discussion_r70833655
--- Diff: core/sql/sqlcomp/CmpSeabaseDDLrepos.cpp ---
@@ -114,43 +123,72 @@ short CmpSeabaseDDL::createRepos(ExeCliInterface *
cliInterface)
}
if (endXnIfStartedHere(cliInterface, xnWasStartedHere, cliRC) < 0)
- return -1;
+ goto label_error;
} // for
+ cliRC = cliInterface->restoreCQD("TRAF_MAX_CHARACTER_COL_LENGTH");
return 0;
+
+ label_error:
+ cliRC = cliInterface->restoreCQD("TRAF_MAX_CHARACTER_COL_LENGTH");
+ return -1;
}
short CmpSeabaseDDL::dropRepos(ExeCliInterface * cliInterface,
NABoolean oldRepos,
- NABoolean dropSchema)
+ NABoolean dropSchema,
+ NABoolean inRecovery)
{
Lng32 cliRC = 0;
-
+ NABoolean xnWasStartedHere = FALSE;
char queryBuf[1000];
for (Int32 i = 0; i < sizeof(allReposUpgradeInfo)/sizeof(MDUpgradeInfo);
i++)
{
const MDUpgradeInfo &rti = allReposUpgradeInfo[i];
+ // If we are dropping the new repository as part of a recovery
action,
+ // and there is no "old" table (because the table didn't change in
this
+ // upgrade), then don't drop the new table. (If we did, we would be
+ // dropping the existing data.)
+ if (!oldRepos && inRecovery && !rti.oldName)
+ continue;
+
if ((oldRepos && !rti.oldName) || (NOT oldRepos && ! rti.newName))
continue;
str_sprintf(queryBuf, "drop table %s.\"%s\".%s cascade; ",
getSystemCatalog(), SEABASE_REPOS_SCHEMA,
(oldRepos ? rti.oldName : rti.newName));
-
+
+ if (beginXnIfNotInProgress(cliInterface, xnWasStartedHere))
+ {
+ cliInterface->retrieveSQLDiagnostics(CmpCommon::diags());
+ return -1;
+ }
+
--- End diff --
What are the plans for transaction management for upgrade? I recently made
a bunch of changed to initialize authorization to allow it to run in a single
transaction. Are we going to run upgrade trafodion in multiple transactions?
> Improve DDL concurrency
> -----------------------
>
> Key: TRAFODION-2037
> URL: https://issues.apache.org/jira/browse/TRAFODION-2037
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: sql-cmu
> Affects Versions: 2.1-incubating
> Environment: All
> Reporter: David Wayne Birdsall
> Assignee: David Wayne Birdsall
>
> In CmpSeabaseDDL::getSeabaseUserTableDesc
> (core/sql/sqlcomp/CmpSeabaseDDLtable.cpp), the code executes the following
> query:
> select trim(O.catalog_name || '.' || '\"' || O.schema_name || '\"' || '.' ||
> '\"' || O.object_name || '\"' ) constr_name, trim(O2.catalog_name || '.' ||
> '\"' || O2.schema_name || '\"' || '.' || '\"' || O2.object_name || '\"' )
> table_name from %s.\"%s\".%s U, %s.\"%s\".%s O, %s.\"%s\".%s O2, %s.\"%s\".%s
> T where O.object_uid = U.foreign_constraint_uid and O2.object_uid =
> T.table_uid and T.constraint_uid = U.foreign_constraint_uid and
> U.unique_constraint_uid = %Ld order by 2, 1
> The plan for this query does a full scan of TABLE_CONSTRAINTS, and joins that
> to OBJECTS_UNIQ_IDX. So all rows of TABLE_CONSTRAINTS are read, and many if
> not most rows of OBJECTS_UNIQ_IDX.
> Analyzing the query plan, the full scan is inherent. The only known
> information we have for TABLE_CONSTRAINTS is CONSTRAINT_UID, which is the
> second column of the key. The first column has high UEC so MDAM is not a
> possibility.
> Creating this large read set conflicts with many write transactions to
> metadata, decreasing DDL concurrency.
> As an experiment, I added an index to the metadata on
> TABLE_CONSTRAINTS(CONSTRAINT_UID). I found I had to add a CQS as well to
> force it to avoid a full scan. With this change, I found that DDL concurrency
> was much improved. So, the proposal in this JIRA is to add this index and CQS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
