[jira] [Updated] (DRILL-7055) Revise SELECT * to exclude partitions
[
https://issues.apache.org/jira/browse/DRILL-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers updated DRILL-7055:
---
Reviewer: (was: Arina Ielchiieva)
> Revise SELECT * to exclude partitions
> -
>
> Key: DRILL-7055
> URL: https://issues.apache.org/jira/browse/DRILL-7055
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Paul Rogers
>Priority: Major
>
> Suppose you have a partitioned table:
> {noformat}
> myTable
> 2018
> file1.csv
> 2019
> file2.csv
> {noformat}
> For some time, Drill has included the partitions in a {{SELECT *}} query:
> {noformat}
> SELECT * FROM `myTable`;
> col1.1, col1.2, 2018
> col2.1, col2.2, 2019
> {noformat}
> There are two subtle issues with this behavior:
> * The behavior of partitions is not consistent with the other file metadata
> (implicit) columns.
> * Because directory depth can vary, and scan order is random, a hard schema
> change can occur if Drill starts scanning shallow files before deep files.
> This ticked proposes to change the partition behavior to be like that of
> other file metadata columns: they are included only when requested:
> {noformat}
> SELECT * FROM `myTable`;
> col1.1, col1.2
> col2.1, col2.2
> SELECT *, dir0, filename FROM `myTable`;
> col1.1, col1.2, 2018, file1.csv
> col2.1, col2.2, 2019, file2.csv
> {noformat}
> With this change, there is no possibility of a hard schema change: the user
> predefines the desired partitions.
> Unfortunately, with the existing readers, a reader that does not have given
> partition will omit that partition column and will instead leave it to the
> projection operator to fill in the column, which it will do with a Nullable
> INT. (The new row-set based scan mechanism handles this case correctly.)
> h4. Risks
> Note that this change does change user-visible behavior. If a user has been
> able to get {{SELECT *}} to work with partition columns, the query will have
> to change to include partition columns. However, it may be that the risk of
> such a breaking change is low because:
> * Users are generally discouraged from using {{SELECT *}} in a production
> query.
> * Use of {{SELECT *}} in a non-uniform partitioning structure would have
> caused failures due to the hard schema change noted above.
> For this reason, the benefits of the change appear to outweigh the risks.
> h4. Technical Background
> In the last year, Calcite appears to have added the ability to specify a
> wildcard plus extra columns. When used with implicit columns, we can now say:
> {code:sql}
> SELECT *, filename FROM myTable;
> {code}
> However, while the readers (at least the CSV reader) can handle this case,
> the {{ProjectRecordBatch}} cannot.
> Modify the {{TestCsv.java}} test case with the following test:
> {code:java}
> @Test
> public void testImplicitColWildcard() throws IOException {
> String sql = "SELECT *, filename FROM `dfs.data`.`%s`";
> RowSet actual = client.queryBuilder().sql(sql, CASE2_FILE_NAME).rowSet();
> actual.print();
> TupleMetadata expectedSchema = new SchemaBuilder()
> .add("a", MinorType.VARCHAR)
> .add("b", MinorType.VARCHAR)
> .add("c", MinorType.VARCHAR)
> .addNullable("filename", MinorType.VARCHAR)
> .buildSchema();
> RowSet expected = new RowSetBuilder(client.allocator(), expectedSchema)
> .addRow("10", "foo", "bar", CASE2_FILE_NAME)
> .build();
> RowSetUtilities.verify(expected, actual);
> }
> {code}
> The output of the {{actual.print()}} is:
> {noformat}
> #: a, b, c, filename
> 0: "10", "foo", "bar", "case2.csv"
> {noformat}
> Now, try the same thing, but substitute "dir0" for "filename". We would
> expect to see something like the above. What we actually see is:
> {noformat}
> #: a, b, c, dir0, dir00
> 0: "10", "foo", "bar", null, null
> {noformat}
> Note that I'm trying this on a "new" CSV reader that fills in "dir0". To see
> the same thing on the master branch, put the CSV file under a directory and
> query the directory.
> The problem is traced to
> [here|https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/project/ProjectRecordBatch.java#L592]:
> {code:java}
> private boolean isImplicitFileColumn(ValueVector vvIn) {
> return
> ColumnExplorer.initImplicitFileColumns(context.getOptions()).get(vvIn.getField().getName())
> != null;
> }
> {code}
> This has two problems:
> 1. It creates a map of implicit column names, but does not handle parsing
> names like "dir0".
> 2. It creates the map over and over: once per column per schema change. Very
> inefficient.
> The solution is to modify the code to use the {{isPartitionColumn()}} method
> in {{ColumnExplorer}}. Plus, create the {{ColumnExplorer}} once per proje
[jira] [Created] (DRILL-7086) Enhance row-set scan framework for to use external schema
Paul Rogers created DRILL-7086: -- Summary: Enhance row-set scan framework for to use external schema Key: DRILL-7086 URL: https://issues.apache.org/jira/browse/DRILL-7086 Project: Apache Drill Issue Type: Improvement Affects Versions: 1.15.0 Reporter: Paul Rogers Assignee: Paul Rogers Modify the row-set scan framework, and the row-set based CSV reader, to use the new schema framework created in DRILL-7073 and related JIRAs. This version is a proof-of-concept. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (DRILL-5954) ListVector shadows "offsets" from BaseRepeatedValueVector
[
https://issues.apache.org/jira/browse/DRILL-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers resolved DRILL-5954.
Resolution: Fixed
Fixed in a prior commit.
> ListVector shadows "offsets" from BaseRepeatedValueVector
> -
>
> Key: DRILL-5954
> URL: https://issues.apache.org/jira/browse/DRILL-5954
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Minor
>
> The Drill vector class {{ListVector}} derives from
> {{BaseRepeatedValueVector}}:
> {code}
> public class ListVector extends BaseRepeatedValueVector {
> private UInt4Vector offsets;
> ...
> {code}
> Note that the {{offsets}} member shadows a member of the same type in the
> super class:
> {code}
> public abstract class BaseRepeatedValueVector ... {
> protected final UInt4Vector offsets;
> ...
> {code}
> In Java, shadowing an existing field is considered bad practice as it is
> never clear which field any particular bit of code references.
> In this case, it appears to be that the {{ListVector}} version is simply a
> reference to the base class version. Perhaps because someone didn't
> understand {{protected}} mode in Java?
> {code}
> public ListVector(MaterializedField field, BufferAllocator allocator,
> CallBack callBack) {
> ...
> offsets = getOffsetVector();
> ...
> {code}
> A quick experiment shows that the {{ListVector}} version can simply be
> removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (DRILL-7055) Revise SELECT * to exclude partitions
[
https://issues.apache.org/jira/browse/DRILL-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers reassigned DRILL-7055:
--
Assignee: (was: Paul Rogers)
> Revise SELECT * to exclude partitions
> -
>
> Key: DRILL-7055
> URL: https://issues.apache.org/jira/browse/DRILL-7055
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Paul Rogers
>Priority: Major
>
> Suppose you have a partitioned table:
> {noformat}
> myTable
> 2018
> file1.csv
> 2019
> file2.csv
> {noformat}
> For some time, Drill has included the partitions in a {{SELECT *}} query:
> {noformat}
> SELECT * FROM `myTable`;
> col1.1, col1.2, 2018
> col2.1, col2.2, 2019
> {noformat}
> There are two subtle issues with this behavior:
> * The behavior of partitions is not consistent with the other file metadata
> (implicit) columns.
> * Because directory depth can vary, and scan order is random, a hard schema
> change can occur if Drill starts scanning shallow files before deep files.
> This ticked proposes to change the partition behavior to be like that of
> other file metadata columns: they are included only when requested:
> {noformat}
> SELECT * FROM `myTable`;
> col1.1, col1.2
> col2.1, col2.2
> SELECT *, dir0, filename FROM `myTable`;
> col1.1, col1.2, 2018, file1.csv
> col2.1, col2.2, 2019, file2.csv
> {noformat}
> With this change, there is no possibility of a hard schema change: the user
> predefines the desired partitions.
> Unfortunately, with the existing readers, a reader that does not have given
> partition will omit that partition column and will instead leave it to the
> projection operator to fill in the column, which it will do with a Nullable
> INT. (The new row-set based scan mechanism handles this case correctly.)
> h4. Risks
> Note that this change does change user-visible behavior. If a user has been
> able to get {{SELECT *}} to work with partition columns, the query will have
> to change to include partition columns. However, it may be that the risk of
> such a breaking change is low because:
> * Users are generally discouraged from using {{SELECT *}} in a production
> query.
> * Use of {{SELECT *}} in a non-uniform partitioning structure would have
> caused failures due to the hard schema change noted above.
> For this reason, the benefits of the change appear to outweigh the risks.
> h4. Technical Background
> In the last year, Calcite appears to have added the ability to specify a
> wildcard plus extra columns. When used with implicit columns, we can now say:
> {code:sql}
> SELECT *, filename FROM myTable;
> {code}
> However, while the readers (at least the CSV reader) can handle this case,
> the {{ProjectRecordBatch}} cannot.
> Modify the {{TestCsv.java}} test case with the following test:
> {code:java}
> @Test
> public void testImplicitColWildcard() throws IOException {
> String sql = "SELECT *, filename FROM `dfs.data`.`%s`";
> RowSet actual = client.queryBuilder().sql(sql, CASE2_FILE_NAME).rowSet();
> actual.print();
> TupleMetadata expectedSchema = new SchemaBuilder()
> .add("a", MinorType.VARCHAR)
> .add("b", MinorType.VARCHAR)
> .add("c", MinorType.VARCHAR)
> .addNullable("filename", MinorType.VARCHAR)
> .buildSchema();
> RowSet expected = new RowSetBuilder(client.allocator(), expectedSchema)
> .addRow("10", "foo", "bar", CASE2_FILE_NAME)
> .build();
> RowSetUtilities.verify(expected, actual);
> }
> {code}
> The output of the {{actual.print()}} is:
> {noformat}
> #: a, b, c, filename
> 0: "10", "foo", "bar", "case2.csv"
> {noformat}
> Now, try the same thing, but substitute "dir0" for "filename". We would
> expect to see something like the above. What we actually see is:
> {noformat}
> #: a, b, c, dir0, dir00
> 0: "10", "foo", "bar", null, null
> {noformat}
> Note that I'm trying this on a "new" CSV reader that fills in "dir0". To see
> the same thing on the master branch, put the CSV file under a directory and
> query the directory.
> The problem is traced to
> [here|https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/project/ProjectRecordBatch.java#L592]:
> {code:java}
> private boolean isImplicitFileColumn(ValueVector vvIn) {
> return
> ColumnExplorer.initImplicitFileColumns(context.getOptions()).get(vvIn.getField().getName())
> != null;
> }
> {code}
> This has two problems:
> 1. It creates a map of implicit column names, but does not handle parsing
> names like "dir0".
> 2. It creates the map over and over: once per column per schema change. Very
> inefficient.
> The solution is to modify the code to use the {{isPartitionColumn()}} method
> in {{ColumnExplorer}}. Plus, create the {{ColumnExplorer}} once per p
[jira] [Commented] (DRILL-6524) Two CASE statements in projection influence results of each other
[
https://issues.apache.org/jira/browse/DRILL-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788807#comment-16788807
]
Volodymyr Vysotskyi commented on DRILL-6524:
The problem here is connected with incorrect scalar replacement. It still
happens even for the case when a reference to the object outside of the
conditional block is changed inside the conditional block. It causes wrong
results for the case when code in this conditional block will not be executed.
The code below demonstrates this issue:
Original class:
{code:java}
package org.apache.drill;
import org.apache.drill.exec.expr.holders.NullableBigIntHolder;
public class CompileClassWithIfs {
public static void doSomething() {
int a = 2;
NullableBigIntHolder out0 = new NullableBigIntHolder();
out0.isSet = 1;
NullableBigIntHolder out4 = new NullableBigIntHolder();
out4.isSet = 0;
if (a == 0) {
out0 = out4;
} else {
}
if (out4.isSet == 0) {
out0.isSet = 1;
} else {
out0.isSet = 0;
assert false : "incorrect value";
}
}
}
{code}
Code after scalar replacement:
{code:java}
package org.apache.drill;
public class CompileClassWithIfs {
public static void doSomething() {
int a = 2;
boolean var1 = false;
long var2 = 0L;
var1 = true;
boolean var4 = false;
long var5 = 0L;
var4 = false;
if (a == 0) {
var1 = var4;
}
if (!var1) {
var1 = true;
} else {
var1 = false;
if (true) {
throw new AssertionError("incorrect value");
}
}
}
public CompileClassWithIfs() {
}
}
{code}
Please note that in the original code, assertion error will not be thrown, but
after scalar replacement {{out0}} and {{out4}} have the same values, so they
were inlined using the same variables.
> Two CASE statements in projection influence results of each other
> -
>
> Key: DRILL-6524
> URL: https://issues.apache.org/jira/browse/DRILL-6524
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.11.0
> Environment: Linux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7
> 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux,
> NAME="CentOS Linux"
> VERSION="7 (Core)"
> apache drill 1.11.0,
> openjdk version "1.8.0_171"
> OpenJDK Runtime Environment (build 1.8.0_171-b10)
> OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode)
>Reporter: Oleksandr Chornyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
> Fix For: 1.16.0
>
>
> h3. Steps to Reproduce
> Run the following query via {{sqlline}}:
> {code:sql}
> select
> case when expr$0 = 3 then expr$0 else expr$1 end,
> case when expr$0 = 1 then expr$0 else expr$1 end
> from (values(1, 2));
> {code}
> h4. Actual Results
> {noformat}
> +-+-+
> | EXPR$0 | EXPR$1 |
> +-+-+
> | 2 | 2 |
> +-+-+
> {noformat}
> h4. Expected Results
> {noformat}
> +-+-+
> | EXPR$0 | EXPR$1 |
> +-+-+
> | 2 | 1 |
> +-+-+
> {noformat}
> Note, that changing order of CASE statements fixes the issue. The following
> query yields correct results:
> {code:sql}
> select
> case when expr$0 = 1 then expr$0 else expr$1 end,
> case when expr$0 = 3 then expr$0 else expr$1 end
> from (values(1, 2));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-6524) Two CASE statements in projection influence results of each other
[
https://issues.apache.org/jira/browse/DRILL-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi updated DRILL-6524:
---
Fix Version/s: 1.16.0
> Two CASE statements in projection influence results of each other
> -
>
> Key: DRILL-6524
> URL: https://issues.apache.org/jira/browse/DRILL-6524
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.11.0
> Environment: Linux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7
> 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux,
> NAME="CentOS Linux"
> VERSION="7 (Core)"
> apache drill 1.11.0,
> openjdk version "1.8.0_171"
> OpenJDK Runtime Environment (build 1.8.0_171-b10)
> OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode)
>Reporter: Oleksandr Chornyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
> Fix For: 1.16.0
>
>
> h3. Steps to Reproduce
> Run the following query via {{sqlline}}:
> {code:sql}
> select
> case when expr$0 = 3 then expr$0 else expr$1 end,
> case when expr$0 = 1 then expr$0 else expr$1 end
> from (values(1, 2));
> {code}
> h4. Actual Results
> {noformat}
> +-+-+
> | EXPR$0 | EXPR$1 |
> +-+-+
> | 2 | 2 |
> +-+-+
> {noformat}
> h4. Expected Results
> {noformat}
> +-+-+
> | EXPR$0 | EXPR$1 |
> +-+-+
> | 2 | 1 |
> +-+-+
> {noformat}
> Note, that changing order of CASE statements fixes the issue. The following
> query yields correct results:
> {code:sql}
> select
> case when expr$0 = 1 then expr$0 else expr$1 end,
> case when expr$0 = 3 then expr$0 else expr$1 end
> from (values(1, 2));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (DRILL-6524) Two CASE statements in projection influence results of each other
[
https://issues.apache.org/jira/browse/DRILL-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi reassigned DRILL-6524:
--
Assignee: Volodymyr Vysotskyi
> Two CASE statements in projection influence results of each other
> -
>
> Key: DRILL-6524
> URL: https://issues.apache.org/jira/browse/DRILL-6524
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.11.0
> Environment: Linux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7
> 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux,
> NAME="CentOS Linux"
> VERSION="7 (Core)"
> apache drill 1.11.0,
> openjdk version "1.8.0_171"
> OpenJDK Runtime Environment (build 1.8.0_171-b10)
> OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode)
>Reporter: Oleksandr Chornyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
>
> h3. Steps to Reproduce
> Run the following query via {{sqlline}}:
> {code:sql}
> select
> case when expr$0 = 3 then expr$0 else expr$1 end,
> case when expr$0 = 1 then expr$0 else expr$1 end
> from (values(1, 2));
> {code}
> h4. Actual Results
> {noformat}
> +-+-+
> | EXPR$0 | EXPR$1 |
> +-+-+
> | 2 | 2 |
> +-+-+
> {noformat}
> h4. Expected Results
> {noformat}
> +-+-+
> | EXPR$0 | EXPR$1 |
> +-+-+
> | 2 | 1 |
> +-+-+
> {noformat}
> Note, that changing order of CASE statements fixes the issue. The following
> query yields correct results:
> {code:sql}
> select
> case when expr$0 = 1 then expr$0 else expr$1 end,
> case when expr$0 = 3 then expr$0 else expr$1 end
> from (values(1, 2));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-7049) REST API returns the toString of byte arrays (VARBINARY types)
[ https://issues.apache.org/jira/browse/DRILL-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jean-claude updated DRILL-7049: --- Description: Doing a query using the REST API will return VARBINARY columns as a Java byte array hashcode instead of the actual data of the VARBINARY. > REST API returns the toString of byte arrays (VARBINARY types) > -- > > Key: DRILL-7049 > URL: https://issues.apache.org/jira/browse/DRILL-7049 > Project: Apache Drill > Issue Type: Bug > Components: Server, Web Server >Affects Versions: 1.15.0 >Reporter: jean-claude >Priority: Minor > Fix For: 1.16.0 > > > Doing a query using the REST API will return VARBINARY columns as a Java byte > array hashcode instead of the actual data of the VARBINARY. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (DRILL-4408) re-written query projecting an aggregate on a boolean not supported by Postgres
[
https://issues.apache.org/jira/browse/DRILL-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi resolved DRILL-4408.
Resolution: Fixed
Fix Version/s: 1.16.0
Fixed in DRILL-5188
> re-written query projecting an aggregate on a boolean not supported by
> Postgres
> ---
>
> Key: DRILL-4408
> URL: https://issues.apache.org/jira/browse/DRILL-4408
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.5.0
>Reporter: N Campbell
>Priority: Major
> Fix For: 1.16.0
>
>
> select rnum, c1, c2 from postgres.public.tset1 as t1 where exists ( select c1
> from postgres.public.tset2 where c1 = t1.c1 )
> Error: DATA_READ ERROR: The JDBC storage plugin failed while trying setup the
> SQL query.
> sql SELECT *
> FROM "public"."tset1"
> INNER JOIN (SELECT "c10", MIN("$f0") AS "$f1"
> FROM (SELECT "t0"."c1" AS "c10", TRUE AS "$f0"
> FROM "public"."tset2"
> INNER JOIN (SELECT "c1"
> FROM (SELECT "c1"
> FROM "public"."tset1") AS "t"
> GROUP BY "c1") AS "t0" ON "tset2"."c1" = "t0"."c1") AS "t1"
> GROUP BY "c10") AS "t2" ON "tset1"."c1" = "t2"."c10"
> plugin postgres
> Fragment 0:0
> [Error Id: a00cd446-f168-463c-b2b9-bb3d6b43e729 on centos1:31010]
> (org.postgresql.util.PSQLException) ERROR: function min(boolean) does not
> exist
> Hint: No function matches the given name and argument types. You might need
> to add explicit type casts.
> Position: 58
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse():2182
> org.postgresql.core.v3.QueryExecutorImpl.processResults():1911
> org.postgresql.core.v3.QueryExecutorImpl.execute():173
> org.postgresql.jdbc.PgStatement.execute():622
> org.postgresql.jdbc.PgStatement.executeWithFlags():458
> org.postgresql.jdbc.PgStatement.executeQuery():374
> org.apache.commons.dbcp.DelegatingStatement.executeQuery():208
> org.apache.commons.dbcp.DelegatingStatement.executeQuery():208
> org.apache.drill.exec.store.jdbc.JdbcRecordReader.setup():177
> org.apache.drill.exec.physical.impl.ScanBatch.():108
> org.apache.drill.exec.physical.impl.ScanBatch.():136
> org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch():40
> org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch():33
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch():147
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren():170
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch():127
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren():170
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch():127
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren():170
> org.apache.drill.exec.physical.impl.ImplCreator.getRootExec():101
> org.apache.drill.exec.physical.impl.ImplCreator.getExec():79
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():230
> org.apache.drill.common.SelfCleaningRunnable.run():38
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745
> SQLState: null
> ErrorCode: 0
> create table TSET1 (RNUM integer not null , C1 integer, C2 char(3));
> create table TSET2 (RNUM integer not null , C1 integer, C2 char(3));
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
