-
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: django failed #106371
Comments
@DrewKimball @andyyang890 it looks like the error from #105598 was not fully fixed by #105866. |
Hmm, maybe it wasn't the same issue after all. @rafiss do you know how I can get the specifics of the failure / failing queries? |
@andyyang890 had found them here: #105598 (comment) But not the DDL/schema. Andy, do you already have those handy? |
I tried getting the list of all the statements that are run but there are way too many (in the order of hundreds). After some trial and error, I was able to create a smaller repro though:
Expected:
Actual:
|
Thanks for the repro! |
roachtest.django failed with artifacts on master @ 43c26aec0072f76e02e6d5ffc1b7079026b24630:
Parameters: |
Self-join equality inference was added by cockroachdb#105214, so that the `FuncDeps` for a self-join would include equalities between *every* pair of columns at the same ordinal position in the base table if there was an equality between key columns (also at the same ordinal position). However, the key column check was performed using the FDs of the join inputs rather than the base table's FDs. This could lead to incorrectly adding self-join equality filters. For example, consider the following: ``` CREATE TABLE xy (x INT NOT NULL, y INT NOT NULL); INSERT INTO xy VALUES (1, 1), (1, 2); SELECT * FROM xy a JOIN xy b ON a.x = b.x; SELECT * FROM (SELECT * FROM xy LIMIT 1) a JOIN (SELECT * FROM xy LIMIT 1) b ON a.x = b.x; ``` In the first query above, `a.x = b.x` does not consitute joining on key columns. But in the second query, both inputs have one row and so *any* set of columns is a key. However, there are no guarantees which row is being joined from each table - if `a` is the `(1, 1)` row and `b` is the `(1, 2)` row, inferring a `a.y = b.y` filter will incorrectly cause the join to return no rows. This patch fixes the problem by requiring the initial self-join equalities to form a key over the *base* table, not just the inputs of the join. Fixes cockroachdb#106371 Release note: None
roachtest.django failed with artifacts on master @ 0207c613fa7c8f3ab66c4518ee1e52dabb863426:
Parameters: |
roachtest.django failed with artifacts on master @ 0207c613fa7c8f3ab66c4518ee1e52dabb863426:
Parameters: |
roachtest.django failed with artifacts on master @ 382a6efb7985b1993e0398c7b29f0e0b746587f4:
Parameters: |
roachtest.django failed with artifacts on master @ a6dbdee0e07325f58a8baf30c199c9cf7ad46614:
Parameters: |
roachtest.django failed with artifacts on master @ 8dcde9c4635f27cefdbc167729c95bf865d9dfd5:
Parameters: |
roachtest.django failed with artifacts on master @ ac6d73de8e27cae4e087bb42ee03bfc515939104:
Parameters: |
roachtest.django failed with artifacts on master @ b4dfdc01809da4ac76b32ec5e2ff9a50d9adeee3:
Parameters: |
roachtest.django failed with artifacts on master @ c609b823b0a1fda5b7d605e4645cd452a6009961:
Parameters: |
roachtest.django failed with artifacts on master @ c89d586897843c96bcf78f143f2c67763819f4a3:
Parameters: |
roachtest.django failed with artifacts on master @ 7675ca4998134028f0623e04737b5cb69fcc33a9:
Parameters: |
Most recent failure is #107056. Leaving open as there are other unresolved failures. |
106485: opt: only infer self-join equality with a key over the base table r=DrewKimball a=DrewKimball #### opt: only infer self-join equality with a key over the base table Self-join equality inference was added by #105214, so that the `FuncDeps` for a self-join would include equalities between *every* pair of columns at the same ordinal position in the base table if there was an equality between key columns (also at the same ordinal position). However, the key column check was performed using the FDs of the join inputs rather than the base table's FDs. This could lead to incorrectly adding self-join equality filters. For example, consider the following: ``` CREATE TABLE t106371 (x INT NOT NULL, y INT NOT NULL); INSERT INTO t106371 VALUES (1, 1), (1, 2); SELECT * FROM t106371 a JOIN t106371 b ON a.x = b.x; SELECT * FROM (SELECT * FROM t106371 ORDER BY y DESC LIMIT 1) a JOIN (SELECT DISTINCT ON (x) * FROM t106371) b ON a.x = b.x; ``` In the first query above, `a.x = b.x` does not consitute joining on key columns. But in the second query, one input has one row and the other de-duplicated by the `x` column and so `x` is a key over both inputs. However, the query as written will select different rows for each input - `a` will return the `(1, 2)` row, while `b` will return the `(1, 1)` row. Inferring a `a.y = b.y` filter will incorrectly cause the join to return no rows. This patch fixes the problem by requiring the initial self-join equalities to form a key over the *base* table, not just the inputs of the join. Fixes #106371 Release note: None 106779: acceptance: Fix DockerCSharp Test r=rimadeodhar a=rimadeodhar This PR updates the .net framework within the csproj setup to .net 6. Additionally, it also fixes the CS program that we run as a part of this test with the new npgsql DateTime changes made as a part of npgsql 6 version update. The old datetime types have been deprecated and needed to be removed. With these fixes, the test is running successfully and can be unskipped. Epic: none Fixes: #86852 Release note: none 107104: cli: fix debug zip with new columns for cluster settings r=maryliag a=maryliag The addition of new columns on cluster_settings view done on #104449 were causing debug zip fails to add the information from that table, since the query used to gather the information was doing a join and not considering the new columns. This commit updates the query to use the explicit columns, so even if new columns are added it won't be a problem in the future. It also adds tests for all custom querys used to generate the debug zip, so this type of issue would have been caught. The file `crdb_internal.cluster_settings.txt` in debug zips was empty due to this bug on v23.1.5 (only version affected by this bug). Fixes #107103 Release note (bug fix): Debug zip now are properly showing the information from cluster_settings. The file `crdb_internal.cluster_settings.txt` in debug zips was empty due to this bug on v23.1.5 (only version affected by this bug). Co-authored-by: Drew Kimball <[email protected]> Co-authored-by: rimadeodhar <[email protected]> Co-authored-by: maryliag <[email protected]>
roachtest.django failed with artifacts on master @ 1137aee0089fc2fe161bab0f1c899d2ddc997c90:
Parameters:
ROACHTEST_arch=amd64
,ROACHTEST_cloud=gce
,ROACHTEST_cpu=16
,ROACHTEST_encrypted=false
,ROACHTEST_ssd=0
Help
See: roachtest README
See: How To Investigate (internal)
This test on roachdash | Improve this report!
Jira issue: CRDB-29537
The text was updated successfully, but these errors were encountered: