-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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: lib/pq failed #57855
Comments
(roachtest).lib/pq failed on master@3018f66208f68fb90c77e3fad01f395a8f10ca8b:
More
Artifacts: /lib/pq
See this test on roachdash |
(roachtest).lib/pq failed on master@152c3b30ae1dcb7a7cefc6aa7fa86c2dd264bd2e:
More
Artifacts: /lib/pq
See this test on roachdash |
(roachtest).lib/pq failed on master@f9b44f59d0451dc9efbb771baac3e88540485629:
More
Artifacts: /lib/pq
See this test on roachdash |
(roachtest).lib/pq failed on master@171cc86d6d84c110197485b5d886d77cddc12399:
More
Artifacts: /lib/pq
See this test on roachdash |
(roachtest).lib/pq failed on master@100c09f4f6eb3f5b18a67ec4bbfdfe989e0d6ce2:
More
Artifacts: /lib/pq
See this test on roachdash |
(roachtest).lib/pq failed on master@81a2c26a104fa8cc7e8b530b837ffb6ff85ddc5a:
More
Artifacts: /lib/pq
See this test on roachdash |
(roachtest).lib/pq failed on master@5971ecb9dd1a25c81cd6012d6be1ff922802eae5:
More
Artifacts: /lib/pq
See this test on roachdash |
@mnovelodou would you be able to figure out what is causing the test to crash? hopefully you can reproduce it locally. |
(roachtest).lib/pq failed on master@15a185606d5e80b47d9fdd0ed4f54cfe29c527c6:
More
Artifacts: /lib/pq
See this test on roachdash |
@RichardJCai It seems like sometimes this test crashes while running. That's what causes the "25 tests expected failed but not run" result -- it aborts before it runs all the tests. Can you try to investigate the cause of the crash? Start with looking in the logs in the TeamCity artifacts. If that's a dead end, then you might need to try running either manually on a GCE worker, or through roachtest and logging into the machine if it crashes. See also #54338 and #56486 for this happening on other branches. |
63238: roachtest: update libpq blocklist to ignore TestCopyInBinaryError r=rafiss a=RichardJCai roachtest: update libpq blocklist to ignore TestCopyInBinaryError TestCopyInBinary's behaviour was incorrect in the test since we were not receiving an expected error (`pq: only text format supported for COPY`). Furthermore the test would sporadically panic causing the following tests to fail. Release note: None Resolves #57855 63244: logictest: compare floating point values approximately on s390x r=ajwerner a=jonathan-albrecht-ibm ### Overview On s390x in the std math package and some c-deps, floating point calculations can produce results that differ from the values calculated on amd64. This patch adds a function to compare logictest floating point and decimal values within a small relative margin on s390x. The existing behavior on all other platforms remains the same. On s390x, there are three main reasons that floating point calculations sometimes give different results: * the go compiler generates the s390x "fused multiply and add" (FMA) instruction where possible, * the go math package uses s390x optimized versions of some functions, * some c libs eg. libgeos, libproj also have platform specific floating point calculation differences. ### Proposal The motivation for this work is so that users building CRDB on s390x do not need to diagnose tests that fail because of platform dependent floating point differences. This PR proposes one possible approach to dealing with platform dependent floating point differences. Since development, testing and CI are done on amd64 it keeps the current logic for determining float equality exactly the same. On s390x, it determines values of decimal and float column types (R and F) in query tests to be equal if they are within a tolerance. See the new pkg/testutils/floatcmp package for the implementation of the approximate equality logic and changes in logictest.go to see how it is applied to only s390x. There are probably other approaches I haven't thought of that would also work. I'd like to use this proposal to start a conversation on how all tests in CRDB that currently fail due to expected floating point differences could eventually be made to pass. Of course platforms other than s390x may also have differences but I haven't looked at any other platforms. The changes should be easily extendable to other platforms if needed. ### Future Work The changes in this PR allow the following tests to pass on s390x: * TestLogic/fakedist-disk/builtin_function/extra_float_digits_3 * TestLogic/fakedist-metadata/builtin_function/extra_float_digits_3 * TestLogic/fakedist-vec-off/builtin_function/extra_float_digits_3 * TestLogic/fakedist/builtin_function/extra_float_digits_3 * TestLogic/local-spec-planning/builtin_function/extra_float_digits_3 * TestLogic/local-vec-off/builtin_function/extra_float_digits_3 * TestLogic/local/builtin_function/extra_float_digits_3 There are about 70 more tests that currently fail due to platform floating point differences on s390x, many are tests of geospatial functions. Assuming we can come up with a good approach, I'd like to continue working on fixes to be submitted in future PRs. Release note: None 63802: colbuilder: optimize IS DISTINCT FROM NULL when null is casted r=yuzefovich a=yuzefovich We have an optimized operator for `Is{Not}DistinctFrom` operation which we can plan currently only if the right side is a constant NULL. In some cases the optimizer might create a cast expression on the right in order to propagate the type of the null, and previously we would fallback to the default comparison operator in such scenario. This is suboptimal, and this commit fixes the issue by special casing the scenario of casting NULL to some type. Fixes: #63792. Release note: None 63903: sql: mark planNodeToRowSource as streaming intelligently r=yuzefovich a=yuzefovich Previously, out of abundance of caution (and some laziness) we marked all `planNodeToRowSource` processors as of "streaming" nature. This marker influences whether we wrap it with a streaming or buffering columnarizer into the vectorized flow. However, doing so is unnecessary in most cases and kills some of the benefits of the vectorized model. The only special planNode is `hookFnNode` which must be streaming, all others are safe to have buffering around them. This commit implements that idea. This required adding another method to `Processor` interface. Release note: None Co-authored-by: richardjcai <[email protected]> Co-authored-by: Jonathan Albrecht <[email protected]> Co-authored-by: Yahor Yuzefovich <[email protected]>
(roachtest).lib/pq failed on master@960b4cfc54c8b78df56e62f07d7a07b986ceacff:
More
Artifacts: /lib/pq
Related:
roachtest: lib/pq failed #56486 roachtest: lib/pq failed C-test-failure O-roachtest O-robot branch-release-20.2
roachtest: lib/pq failed #54338 roachtest: lib/pq failed C-test-failure O-roachtest O-robot branch-release-20.1
See this test on roachdash
powered by pkg/cmd/internal/issues
The text was updated successfully, but these errors were encountered: