Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

roachtest: do not fail costfuzz test on perturbed error #81416

Merged
merged 1 commit into from
May 18, 2022

Conversation

michae2
Copy link
Collaborator

@michae2 michae2 commented May 18, 2022

The costfuzz test repeatedly executes a randomly generated query twice,
once with a normal plan and once with a perturbed-costs plan. We were
considering a successful first execution followed by an errored second
execution a test failure. But there are certain queries that
legitimately return errors nondeterministically depending on plan. For
example:

CREATE TABLE t (a INT PRIMARY KEY);
CREATE TABLE u (b INT PRIMARY KEY);
INSERT INTO t VALUES (0);
SELECT * FROM t INNER HASH JOIN u ON a = b + 1 WHERE 1 / a = 1;
SELECT * FROM u INNER HASH JOIN t ON a = b + 1 WHERE 1 / a = 1;

The first plan will successfully return 0 rows because the hash join can
short-circuit without evaluating 1 / a. The second plan will return a
divide-by-zero error because 1 / a is evaluated while building the hash
table. This is not a bug.

Internal errors are a little more interesting than normal SQL-level
errors, so we still consider this a test failure on internal errors.

Fixes: #81032

Release note: None

The costfuzz test repeatedly executes a randomly generated query twice,
once with a normal plan and once with a perturbed-costs plan. We were
considering a successful first execution followed by an errored second
execution a test failure. But there are certain queries that
legitimately return errors nondeterministically depending on plan. For
example:

```sql
CREATE TABLE t (a INT PRIMARY KEY);
CREATE TABLE u (b INT PRIMARY KEY);
INSERT INTO t VALUES (0);
SELECT * FROM t INNER HASH JOIN u ON a = b + 1 WHERE 1 / a = 1;
SELECT * FROM u INNER HASH JOIN t ON a = b + 1 WHERE 1 / a = 1;
```

The first plan will successfully return 0 rows because the hash join can
short-circuit without evaluating 1 / a. The second plan will return a
divide-by-zero error because 1 / a is evaluated while building the hash
table. This is not a bug.

Internal errors are a little more interesting than normal SQL-level
errors, so we still consider this a test failure on internal errors.

Fixes: cockroachdb#81032

Release note: None
@michae2 michae2 requested review from mgartner, msirek and a team May 18, 2022 00:04
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Contributor

@msirek msirek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @mgartner)

@michae2
Copy link
Collaborator Author

michae2 commented May 18, 2022

TFTR!

bors r=msirek

@craig
Copy link
Contributor

craig bot commented May 18, 2022

Build failed (retrying...):

@craig
Copy link
Contributor

craig bot commented May 18, 2022

Build succeeded:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

roachtest: costfuzz failed
3 participants