core_test: add cases that local temporary table works well for cte

[zhaoxugang]

What problem does this PR solve?

Issue Number: close #25951

Problem Summary:

What is changed and how it works?

Proposal: xxx

What's Changed:

How it Works:

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• djshow832
• lcwangchao

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[wjhuang2016]

MySQL:

mysql> drop table t1;
Query OK, 0 rows affected (0.02 sec)

mysql>  create temporary table t1 (i int);
Query OK, 0 rows affected (0.01 sec)

mysql>  insert into t1 values (5),(4),(1),(2),(3);
Query OK, 5 rows affected (0.01 sec)
Records: 5  Duplicates: 0  Warnings: 0
mysql> with cte as (select * from t1) select * from cte;
+------+
| i    |
+------+
|    5 |
|    4 |
|    1 |
|    2 |
|    3 |
+------+
5 rows in set (0.00 sec)

[zhaoxugang]

/rebuild

[zhaoxugang]

/rebuild

[Howie59]

it seems like this line is duplicated with 3846, could we simplify the code?

[zhaoxugang]

done

[Howie59]

how about return nil, ErrInternal.GenWithStack(errno.MySQLErrName[errno.ErrCantReopenTable].Raw,tb.Meta().Name.L)

[zhaoxugang]

done

[tiancaiamao]

The correct usage should be:

1. define a global error object in this package, maybe error.go

errCantReopenTable =  dbterror.ClassTypes.NewStdErr(errno.ErrCantReopenTable, mysql.MySQLErrName[errno.ErrCantReopenTable])

2. and then use errCantReopenTable.GenWithStackByArgs(tblName) here

In this way, you can get the correct error code 1137, instead of 1815

@zhaoxugang

[lcwangchao]

The title is misleading, it is not "Forbid cte on the local temporary table". It should be "Forbade refer temporary table more than once in one statement"

[lcwangchao]

@zhaoxugang You can just put a None in release note if nothing to write.

[djshow832]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: b5ebd02

[djshow832]

FAIL: <autogenerated>:1: testSerialSuite.TestTemporaryTableNoNetwork
The CI failed, but probably not related to this PR. Can you take a look? @lcwangchao

[lcwangchao]

FAIL: <autogenerated>:1: testSerialSuite.TestTemporaryTableNoNetwork
The CI failed, but probably not related to this PR. Can you take a look? @lcwangchao

I think it's caused by #27405

The test has a goroutine:

go func() {
    _, err := session.ResultSetToStringSlice(ctx, tk1.Se, rs)
    blocked <- struct{}{}
    c.Assert(err, NotNil)
}()

The old version will always be blocked because blocked by blocked <- struct{}{} channel has a zero capacity. In a right case, none will consume it.

So the pr #27405 made some change:

- blocked := make(chan struct{})
+ blocked := make(chan struct{}, 1)

The chan will not be blocked any more, but unfortunately, this line in the goroutine function will alway fail:

c.Assert(err, NotNil)

So the test failed. (If we invoked cancel for a context, the best behavior is return an error. I don't know why it doesn't)

But the test failed in my laptop for another reason:

goleak: Errors on successful test run: found unexpected goroutines:

I think it is because #27405 added goleak to detected leaks but sometimes the goroutine did not exist so quickly.

But It is still strange that the context cancel function is called very early, but in my own environment, it fails as a leak for most cases. So I found that: after we call cancel, the goroutine is still blocked in this line:

_, err := session.ResultSetToStringSlice(ctx, tk1.Se, rs)

And this line is blocked by:

err = rs.Close()

So I know that rs.Close() is always blocked until the failpoint is disabled. (I still wonder why we make a blocking close function).

To avoid this error, we just need to remove c.Assert(err, NotNil) wait for the goroutine exited before the end of test.

[ti-chi-bot]

@zhaoxugang: Your PR was out of date, I have automatically updated it for you.

At the same time I will also trigger all tests for you:

/run-all-tests

If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.