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

[CI] arrow-compute: ExecPlanExecution.StressSourceOrderBy may failed #15141

Closed
mapleFU opened this issue Dec 31, 2022 · 1 comment · Fixed by #15142
Closed

[CI] arrow-compute: ExecPlanExecution.StressSourceOrderBy may failed #15141

mapleFU opened this issue Dec 31, 2022 · 1 comment · Fixed by #15142
Assignees
Milestone

Comments

@mapleFU
Copy link
Member

mapleFU commented Dec 31, 2022

Describe the bug, including details regarding any error messages, version, and platform.

  1. https://github.com/apache/arrow/actions/runs/3812471160/jobs/6485697443
  2. https://github.com/apache/arrow/actions/runs/3808810467/jobs/6479699758

Seems that the case may failed. And I didn't modify the case which could cause it failed.

Component(s)

C++

@westonpace
Copy link
Member

Thanks for the report. I probably introduced this with #15104

westonpace added a commit that referenced this issue Jan 1, 2023
The sorting done by orderby is not stable.  This means, given the input:

a | b
--- | ---
1 | false
1 | true

the test could have generated both `[false, true]` and `[true, false]` for the `b` column.  We likely did not encounter this before 498b645 because the entire thing was run serially (even though there was a `parallel` option it was not setup correctly).

Now that things are properly running parallel the results are non-deterministic.  We could remove the `b` column but I feel it is a better stress test to have at least one payload column.  So I changed the test to only compare the key array and not the payload array.
* Closes: #15141

Authored-by: Weston Pace <weston.pace@gmail.com>
Signed-off-by: Weston Pace <weston.pace@gmail.com>
@westonpace westonpace added this to the 11.0.0 milestone Jan 1, 2023
EpsilonPrime pushed a commit to EpsilonPrime/arrow that referenced this issue Jan 5, 2023
…che#15142)

The sorting done by orderby is not stable.  This means, given the input:

a | b
--- | ---
1 | false
1 | true

the test could have generated both `[false, true]` and `[true, false]` for the `b` column.  We likely did not encounter this before apache@498b645 because the entire thing was run serially (even though there was a `parallel` option it was not setup correctly).

Now that things are properly running parallel the results are non-deterministic.  We could remove the `b` column but I feel it is a better stress test to have at least one payload column.  So I changed the test to only compare the key array and not the payload array.
* Closes: apache#15141

Authored-by: Weston Pace <weston.pace@gmail.com>
Signed-off-by: Weston Pace <weston.pace@gmail.com>
EpsilonPrime pushed a commit to EpsilonPrime/arrow that referenced this issue Jan 5, 2023
…che#15142)

The sorting done by orderby is not stable.  This means, given the input:

a | b
--- | ---
1 | false
1 | true

the test could have generated both `[false, true]` and `[true, false]` for the `b` column.  We likely did not encounter this before apache@498b645 because the entire thing was run serially (even though there was a `parallel` option it was not setup correctly).

Now that things are properly running parallel the results are non-deterministic.  We could remove the `b` column but I feel it is a better stress test to have at least one payload column.  So I changed the test to only compare the key array and not the payload array.
* Closes: apache#15141

Authored-by: Weston Pace <weston.pace@gmail.com>
Signed-off-by: Weston Pace <weston.pace@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants