Open cockroach-teamcity opened 3 weeks ago
pkg/ccl/testccl/workload/schemachange/schemachange_test.TestWorkload failed on release-24.1.2-rc @ 4037be1494ff8f3873edfa2510a7fa79545b413e:
},
{
"query": "SELECT ARRAY[parent.table_schema, parent.table_name, quote_ident(parent.column_name), quote_ident(child.column_name)] FROM (SELECT conname, conkey, confkey, conrelid, confrelid FROM pg_constraint WHERE (contype = 'f') AND (conrelid = 'schema_w0_16.table_w0_55'::REGCLASS::INT8)) AS con JOIN (SELECT column_name, ordinal_position, column_default FROM information_schema.columns WHERE (table_schema = 'schema_w0_16') AND (table_name = 'table_w0_55')) AS child ON conkey[1] = child.ordinal_position JOIN (SELECT pc.oid, cols.table_schema, cols.table_name, cols.column_name, cols.ordinal_position FROM pg_class AS pc JOIN pg_namespace AS pn ON pc.relnamespace = pn.oid JOIN information_schema.columns AS cols ON ((pc.relname = cols.table_name) AND (pn.nspname = cols.table_schema))) AS parent ON ((con.confkey[1] = parent.ordinal_position) AND (con.confrelid = parent.oid)) WHERE child.column_name != 'rowid'",
"result": null
}
],
"previousStatements": [
"CREATE TABLE schema_w0_16.table_w0_55 (\"col55 _w0_56\" FLOAT4 NOT NULL, col5̏5_w0_57 BOX2D NULL, \"!col55_w0_58\" GEOGRAPHY NOT NULL, col55_w0_59 VARCHAR NOT NULL, UNIQUE (col55_w0_59 ASC) STORING (\"col55 _w0_56\", \"!col55_w0_58\"), INDEX (\"col55 _w0_56\"), UNIQUE ((\"col55 _w0_56\" + 0.2537466883659363:::FLOAT8)), INDEX (col5̏5_w0_57 DESC) STORING (col55_w0_59), UNIQUE (\"col55 _w0_56\", col5̏5_w0_57 ASC), INDEX (\"col55 _w0_56\" DESC) STORING (\"!col55_w0_58\") PARTITION BY LIST (\"col55 _w0_56\") (PARTITION \"tabl\\\\u4596e_55_part_0\" VALUES IN ((0.0:::FLOAT8,)), PARTITION \"t abl\\\\u4596e_55_part_1\" VALUES IN (((-1.199499487876892):::FLOAT8,)), PARTITION \"tabl\\\\u4596e_55_part_2\" VALUES IN ((1.2670646905899048:::FLOAT8,)), PARTITION \"tabl\\\\u4596e_55_part_3\" VALUES IN (((-0.20344634354114532):::FLOAT8,))), INDEX (\"col55 _w0_56\" ASC, (\"col55 _w0_56\" + 0.37552177906036377:::FLOAT8) DESC))",
"INSERT INTO schema_w0_16.table_w0_55 (\"col55 _w0_56\",col5̏5_w0_57,\"!col55_w0_58\",col55_w0_59) VALUES ((-1.526540994644165):::FLOAT8,'BOX(-1.1303581340633653 -0.512563710369231,1.5282298679786184 -0.2914727525549499)':::BOX2D,'01040000A0E61000000100000001010000802031ED1A01CD4440C04FEB9C531E4EC0D0B1C37E6D4AD341':::GEOGRAPHY,''::VARCHAR),(1.401298464324817e-45:::FLOAT8,NULL,'0102000020E610000002000000CC9DF003984E5D403DB15B7023A752C088911BF7F22E5540882DCA8B9B952EC0':::GEOGRAPHY,'X'::VARCHAR),(0.9389936327934265:::FLOAT8,'BOX(0.18654400235352142 0.45372436372591257,0.649556289075322 1.466738206995367)':::BOX2D,'0104000020E610000000000000':::GEOGRAPHY,e'R``[\\f(lX'::VARCHAR)",
"INSERT INTO schema_w0_16.table_w0_55 (\"col55 _w0_56\",col5̏5_w0_57,\"!col55_w0_58\",col55_w0_59) VALUES (0.0:::FLOAT8,'BOX(-0.851823137270188 -1.0970450541832317,0.42869979121301593 0.0778694338778807)':::BOX2D,'0106000020E61000000900000001030000000100000005000000C0C4BC3CD1F65FC0E8E262DDDA054AC0C81894E4B07F5BC00970D735843756C08E88967964965BC05C9D393BF7964E40B512811D224A63C052BF600DCF055540C0C4BC3CD1F65FC0E8E262DDDA054AC001030000000100000008000000E8A0B27D65A858C04F7B51E0408551C099174886009155C0A1DB53B0392B54C0445541589EAB5C40E59DCABA6B5848C0C47CB5634AB95840ECB805E5CA903C40F8813E54261A4440FECB62EB2F90544080C4EF0857DC45C09835127EC03C5440C6310A2AAD985FC000B6B4CC24925540E8A0B27D65A858C04F7B51E0408551C0010300000001000000040000007CAA8D7C0B6360C0E7C4D10525B354C054CCA985BE4A474008C64FEDBA2150401D0890D673D95BC0882952E92A5656407CAA8D7C0B6360C0E7C4D10525B354C001030000000100000006000000C031734E7A9B2B40C505B5F2DA2546C0D40177131C455E40DC01275B3AB43DC07CF4D219F51E6440A0F0F88A056417404651EFA2A7684FC0F0B6BF36E5565640B0D6B5748D4466C0802C2A06C52E3A40C031734E7A9B2B40C505B5F2DA2546C00103000000010000000D000000B45737C4E92866C010E76AA1FF8230C0D04BF453301562C019487C0FA61342C031DCB104962366C08ED17448FEA44DC07017345B1D4464C05AE1C2A1288250C0A8700DBE02FE4FC00C08D600044356C0B0211EC704C44E40167D366A1BB647C080007CF9F6BC2C40EEE3E348B4C23EC0E6B18E0D53B6624080FDA8D9E431EFBF006258B53497E3BF50828ED0E77910C089BF397FFD8D5CC05816573FAE84484064453A2A846766C006E26C443B4856409357BC7E845E65C03C51564522AE3540B45737C4E92866C010E76AA1FF8230C00103000000010000000A000000F6D6EACF1E6D64C03A550EABCE8655C08194601319B851C0103717AE3FE04DC0A0D5812B7C9734C0AEAF0FA3B29A52C0584A69958A2C4040343A371ADF0452C054B31393283D64403E46A4AB32674BC060B20A9BC76724C0DCC1632C245D54402E35EA20942852C04480AF8DAE654940BE874612510B58C06079E5BDFD8F0E402B518DB2396461C0E40A92BED6C933C0F6D6EACF1E6D64C03A550EABCE8655C00103000000010000000A00000046EB55492D4258C099C0FC0A375A55C020B2F7BFA6751BC0A49BC44F957445C0FEE78317DD02654008E9137CA33F54C0D41FB0B1F8E151408054476381F834C0D0A0FEEAAA8A58407013983D5C7C15C0E495687B743656408014AC7B824F15C0687E35D7CF7D5F4010E36FE9D6FC1A40F05AF5FB6C5743C004BD6CAB0CCE4040478C72C3C63F66C0589EA28FCC75514046EB55492D4258C099C0FC0A375A55C001030000000100000006000000E8A7C3930DFE3CC0DC29C545CAC94BC040DE27A1A0D802C01C27EC54D2C444C0E8B3EB260EBA3B4060A8895DAE724340607654A9598A2340CE64295790B65040A41167D800D85BC0683052B163A73340E8A7C3930DFE3CC0DC29C545CAC94BC001030000000100000009000000046B8E14D69265C0B0DB9456E86D4BC02E9148C1F8CF61C0078E880A25254AC0F067D9BC3065314030713B877D5D55C0F8A667306AD554403A66A86D813748C0C0098C59809F41C028C9BCBA8AEF3BC0E3266C81B83D52C0EC73F493106B4F401F62ED76DC8856C0B05441A460C61140B99EE00EBE3464C0A8B0C63E987A2340046B8E14D69265C0B0DB9456E86D4BC0':::GEOGRAPHY,e'E\\x04'::VARCHAR)"
]
}
}
schema_change_external_test.go:132:
Error Trace: pkg/ccl/testccl/workload/schemachange/schemachange_test_test/pkg/ccl/testccl/workload/schemachange/schema_change_external_test.go:132
Error: Received unexpected error:
***UNEXPECTED ERROR; Received an unexpected execution error.: ERROR: duplicate key value violates unique constraint "table_w0_55_expr_key" (SQLSTATE 23505)
(1) forced error mark
| "fatal error when running txn"
| github.com/cockroachdb/errors/withstack/*withstack.withStack::
Wraps: (2)
Wraps: (3) attached stack trace
-- stack trace:
| github.com/cockroachdb/cockroach/pkg/workload/schemachange.(*opStmt).executeStmt
| github.com/cockroachdb/cockroach/pkg/workload/schemachange/operation_generator.go:3120
| github.com/cockroachdb/cockroach/pkg/workload/schemachange.(*schemaChangeWorker).runInTxn
| github.com/cockroachdb/cockroach/pkg/workload/schemachange/schemachange.go:511
| github.com/cockroachdb/cockroach/pkg/workload/schemachange.(*schemaChangeWorker).run
| github.com/cockroachdb/cockroach/pkg/workload/schemachange/schemachange.go:605
| pkg/ccl/testccl/workload/schemachange/schemachange_test_test.TestWorkload.TestWorkload.func4.func6
| pkg/ccl/testccl/workload/schemachange/schemachange_test_test/pkg/ccl/testccl/workload/schemachange/schema_change_external_test.go:121
| golang.org/x/sync/errgroup.(*Group).Go.func1
| golang.org/x/sync/errgroup/external/org_golang_x_sync/errgroup/errgroup.go:78
| runtime.goexit
| src/runtime/asm_amd64.s:1695
Wraps: (4) ***UNEXPECTED ERROR; Received an unexpected execution error.
Wraps: (5) ERROR: duplicate key value violates unique constraint "table_w0_55_expr_key" (SQLSTATE 23505)
Error types: (1) *markers.withMark (2) *schemachange.ErrorState (3) *withstack.withStack (4) *errutil.withPrefix (5) *pgconn.PgError
Test: TestWorkload
Schema Workload Stats
Total Schema Statements Executed = 103
Total Schema Statements Succeeded = 103
Total Schema Statement Expected Failures = 0
Total Transactions Committed = 64
Total Transactions Rolled Back = 87
Total Transactions Executed = 151
schema_change_external_test.go:98: backup, tracing data, and system table dumps in /var/lib/engflow/worker/work/0/exec/bazel-out/k8-fastbuild/testlogs/pkg/ccl/testccl/workload/schemachange/schemachange_test/run_8_of_25/test.outputs/logTestWorkload1471406582
panic.go:626: -- test log scope end --
test logs left over in: outputs.zip/logTestWorkload1471406582
--- FAIL: TestWorkload (24.32s)
Parameters:
attempt=1
run=8
shard=1
the inserts are essentially doing:
demo@127.0.0.1:26257/movr> CREATE TEMP VIEW temp_view AS
-> SELECT
-> original_value,
-> (original_value + 0.2537466883659363) AS
-> modified_value
-> FROM (
-> VALUES
-> (-1.526540994644165:::FLOAT8),
-> (1.401298464324817e-45:::FLOAT8),
-> (0.9389936327934265:::FLOAT8),
-> (0.0:::FLOAT8)
-> ) AS v(original_value);
CREATE VIEW
Time: 6ms total (execution 6ms / network 0ms)
demo@127.0.0.1:26257/movr> select * from temp_view;
original_value | modified_value
------------------------+----------------------
-1.526540994644165 | -1.2727943062782288
1.401298464324817e-45 | 0.2537466883659363
0.9389936327934265 | 1.1927403211593628
0 | 0.2537466883659363
(4 rows)
Time: 5ms total (execution 4ms / network 0ms)
(original_value + 0.2537466883659363) is the unique constraint
i thought we had something to prevent this from happening... let me take a quick peek
i investigated by looking for queries like:
SELECT count(*) \u003e 0 FROM (SELECT * FROM schema_w0_16.table_w0_55 WHERE (\"col55 _w0_56\" + 0.2537466883659363:::FLOAT8) = (SELECT (\"col55 _w0_56\" + 0.2537466883659363:::FLOAT8) FROM (VALUES (0.9389936327934265:::FLOAT8)) AS t (\"col55 _w0_56\")))
these queries come from this part of our schemachange code:
https://github.com/cockroachdb/cockroach/blob/0823fda427341de8bfb6823332cc4ea7508575b8/pkg/workload/schemachange/error_screening.go#L351
in valuesViolateUniqueConstraints
there are several of them comparing our unique constraint (\"col55 _w0_56\" + 0.2537466883659363:::FLOAT8), but they are "batched out" (i.e. we check one value at a time againt the table) since i believe we only check if values that we are inserting violate the unqiue constraint with values that already exist in the table -- not in the same insert
gpt4 gave me something like -- leaving this here in case this is helpful for coming up with said query above:
SELECT
EXISTS (
SELECT
result_value
FROM
(
SELECT
("col55_w0_56" + 0.2537466883659363:::FLOAT8) AS result_value
FROM
(
VALUES
(-1.526540994644165:::FLOAT8),
(1.401298464324817e-45:::FLOAT8),
(0.9389936327934265:::FLOAT8),
(0.0:::FLOAT8)
) AS t ("col55_w0_56")
) AS results
GROUP BY
result_value
HAVING
COUNT(*) > 1
) AS has_duplicates;
Including the table definition here too:
{
"workerId": 0,
"clientTimestamp": "06:32:42.703608",
"ops": [
"BEGIN",
{
"sql": "CREATE TABLE schema_w0_16.table_w0_55 (\"col55 _w0_56\" FLOAT4 NOT NULL, col5̏5_w0_57 BOX2D NULL, \"!col55_w0_58\" GEOGRAPHY NOT NULL, col55_w0_59 VARCHAR NOT NULL, UNIQUE (col55_w0_59 ASC) STORING (\"col55 _w0_56\", \"!col55_w0_58\"), INDEX (\"col55 _w0_56\"), UNIQUE ((\"col55 _w0_56\" + 0.2537466883659363:::FLOAT8)), INDEX (col5̏5_w0_57 DESC) STORING (col55_w0_59), UNIQUE (\"col55 _w0_56\", col5̏5_w0_57 ASC), INDEX (\"col55 _w0_56\" DESC) STORING (\"!col55_w0_58\") PARTITION BY LIST (\"col55 _w0_56\") (PARTITION \"tabl\\\\u4596e_55_part_0\" VALUES IN ((0.0:::FLOAT8,)), PARTITION \"t abl\\\\u4596e_55_part_1\" VALUES IN (((-1.199499487876892):::FLOAT8,)), PARTITION \"tabl\\\\u4596e_55_part_2\" VALUES IN ((1.2670646905899048:::FLOAT8,)), PARTITION \"tabl\\\\u4596e_55_part_3\" VALUES IN (((-0.20344634354114532):::FLOAT8,))), INDEX (\"col55 _w0_56\" ASC, (\"col55 _w0_56\" + 0.37552177906036377:::FLOAT8) DESC))"
},
{
"sql": "INSERT INTO schema_w0_16.table_w0_55 (\"col55 _w0_56\",col5̏5_w0_57,\"!col55_w0_58\",col55_w0_59) VALUES ((-1.526540994644165):::FLOAT8,'BOX(-1.1303581340633653 -0.512563710369231,1.5282298679786184 -0.2914727525549499)':::BOX2D,'01040000A0E61000000100000001010000802031ED1A01CD4440C04FEB9C531E4EC0D0B1C37E6D4AD341':::GEOGRAPHY,''::VARCHAR),(1.401298464324817e-45:::FLOAT8,NULL,'0102000020E610000002000000CC9DF003984E5D403DB15B7023A752C088911BF7F22E5540882DCA8B9B952EC0':::GEOGRAPHY,'X'::VARCHAR),(0.9389936327934265:::FLOAT8,'BOX(0.18654400235352142 0.45372436372591257,0.649556289075322 1.466738206995367)':::BOX2D,'0104000020E610000000000000':::GEOGRAPHY,e'R`[\\f(lX'::VARCHAR)"
},
{
"sql": "INSERT INTO schema_w0_16.table_w0_55 (\"col55 _w0_56\",col5̏5_w0_57,\"!col55_w0_58\",col55_w0_59) VALUES (0.0:::FLOAT8,'BOX(-0.851823137270188 -1.0970450541832317,0.42869979121301593 0.0778694338778807)':::BOX2D,'0106000020E61000000900000001030000000100000005000000C0C4BC3CD1F65FC0E8E262DDDA054AC0C81894E4B07F5BC00970D735843756C08E88967964965BC05C9D393BF7964E40B512811D224A63C052BF600DCF055540C0C4BC3CD1F65FC0E8E262DDDA054AC001030000000100000008000000E8A0B27D65A858C04F7B51E0408551C099174886009155C0A1DB53B0392B54C0445541589EAB5C40E59DCABA6B5848C0C47CB5634AB95840ECB805E5CA903C40F8813E54261A4440FECB62EB2F90544080C4EF0857DC45C09835127EC03C5440C6310A2AAD985FC000B6B4CC24925540E8A0B27D65A858C04F7B51E0408551C0010300000001000000040000007CAA8D7C0B6360C0E7C4D10525B354C054CCA985BE4A474008C64FEDBA2150401D0890D673D95BC0882952E92A5656407CAA8D7C0B6360C0E7C4D10525B354C001030000000100000006000000C031734E7A9B2B40C505B5F2DA2546C0D40177131C455E40DC01275B3AB43DC07CF4D219F51E6440A0F0F88A056417404651EFA2A7684FC0F0B6BF36E5565640B0D6B5748D4466C0802C2A06C52E3A40C031734E7A9B2B40C505B5F2DA2546C00103000000010000000D000000B45737C4E92866C010E76AA1FF8230C0D04BF453301562C019487C0FA61342C031DCB104962366C08ED17448FEA44DC07017345B1D4464C05AE1C2A1288250C0A8700DBE02FE4FC00C08D600044356C0B0211EC704C44E40167D366A1BB647C080007CF9F6BC2C40EEE3E348B4C23EC0E6B18E0D53B6624080FDA8D9E431EFBF006258B53497E3BF50828ED0E77910C089BF397FFD8D5CC05816573FAE84484064453A2A846766C006E26C443B4856409357BC7E845E65C03C51564522AE3540B45737C4E92866C010E76AA1FF8230C00103000000010000000A000000F6D6EACF1E6D64C03A550EABCE8655C08194601319B851C0103717AE3FE04DC0A0D5812B7C9734C0AEAF0FA3B29A52C0584A69958A2C4040343A371ADF0452C054B31393283D64403E46A4AB32674BC060B20A9BC76724C0DCC1632C245D54402E35EA20942852C04480AF8DAE654940BE874612510B58C06079E5BDFD8F0E402B518DB2396461C0E40A92BED6C933C0F6D6EACF1E6D64C03A550EABCE8655C00103000000010000000A00000046EB55492D4258C099C0FC0A375A55C020B2F7BFA6751BC0A49BC44F957445C0FEE78317DD02654008E9137CA33F54C0D41FB0B1F8E151408054476381F834C0D0A0FEEAAA8A58407013983D5C7C15C0E495687B743656408014AC7B824F15C0687E35D7CF7D5F4010E36FE9D6FC1A40F05AF5FB6C5743C004BD6CAB0CCE4040478C72C3C63F66C0589EA28FCC75514046EB55492D4258C099C0FC0A375A55C001030000000100000006000000E8A7C3930DFE3CC0DC29C545CAC94BC040DE27A1A0D802C01C27EC54D2C444C0E8B3EB260EBA3B4060A8895DAE724340607654A9598A2340CE64295790B65040A41167D800D85BC0683052B163A73340E8A7C3930DFE3CC0DC29C545CAC94BC001030000000100000009000000046B8E14D69265C0B0DB9456E86D4BC02E9148C1F8CF61C0078E880A25254AC0F067D9BC3065314030713B877D5D55C0F8A667306AD554403A66A86D813748C0C0098C59809F41C028C9BCBA8AEF3BC0E3266C81B83D52C0EC73F493106B4F401F62ED76DC8856C0B05441A460C61140B99EE00EBE3464C0A8B0C63E987A2340046B8E14D69265C0B0DB9456E86D4BC0':::GEOGRAPHY,e'E\\x04'::VARCHAR)"
}
],
"expectedExecErrors": "",
"expectedCommitErrors": "",
"message": "***UNEXPECTED ERROR; Received an unexpected execution error.: ERROR: duplicate key value violates unique constraint \"table_w0_55_expr_key\" (SQLSTATE 23505)",
I wonder if we need to do something to not define a unique constraint on a computed column that is based on a nullable value.
Simplest possible repro of his problem is:
CREATE TABLE schema_w0_16.table_w0_55 ("col55 _w0_56" FLOAT4 NOT NULL, col5̏5_w0_57 BOX2D NULL, "!col55_w0_58" GEOGRAPHY NOT NULL, col55_w0_59 VARCHAR NOT NULL, UNIQUE (col55_w0_59 ASC) STORING ("col55 _w0_56", "!col55_w0_58"), INDEX ("col55 _w0_56"), UNIQUE (("col55 _w0_56" + 0.2537466883659363:::FLOAT8)), INDEX (col5̏5_w0_57 DESC) STORING (col55_w0_59), UNIQUE ("col55 _w0_56", col5̏5_w0_57 ASC), INDEX ("col55 _w0_56" DESC) STORING ("!col55_w0_58") PARTITION BY LIST ("col55 _w0_56") (PARTITION "tabl\\\\u4596e_55_part_0" VALUES IN ((0.0:::FLOAT8,)), PARTITION "t abl\\\\u4596e_55_part_1" VALUES IN (((-1.199499487876892):::FLOAT8,)), PARTITION "tabl\\\\u4596e_55_part_2" VALUES IN ((1.2670646905899048:::FLOAT8,)), PARTITION "tabl\\\\u4596e_55_part_3" VALUES IN (((-0.20344634354114532):::FLOAT8,))), INDEX ("col55 _w0_56" ASC, ("col55 _w0_56" + 0.37552177906036377:::FLOAT8) DESC));
INSERT INTO schema_w0_16.table_w0_55 ("col55 _w0_56",col5̏5_w0_57,"!col55_w0_58",col55_w0_59) VALUES ((-1.526540994644165):::FLOAT8,'BOX(-1.1303581340633653 -0.512563710369231,1.5282298679786184 -0.2914727525549499)':::BOX2D,'01040000A0E61000000100000001010000802031ED1A01CD4440C04FEB9C531E4EC0D0B1C37E6D4AD341':::GEOGRAPHY,''::VARCHAR),(1.401298464324817e-45:::FLOAT8,NULL,'0102000020E610000002000000CC9DF003984E5D403DB15B7023A752C088911BF7F22E5540882DCA8B9B952EC0':::GEOGRAPHY,'X'::VARCHAR),(0.9389936327934265:::FLOAT8,'BOX(0.18654400235352142 0.45372436372591257,0.649556289075322 1.466738206995367)':::BOX2D,'0104000020E610000000000000':::GEOGRAPHY,e'R``[\\f(lX'::VARCHAR);
INSERT INTO schema_w0_16.table_w0_55 ("col55 _w0_56",col5̏5_w0_57,"!col55_w0_58",col55_w0_59) VALUES (0.0:::FLOAT8,'BOX(-0.851823137270188 -1.0970450541832317,0.42869979121301593 0.0778694338778807)':::BOX2D,'0106000020E61000000900000001030000000100000005000000C0C4BC3CD1F65FC0E8E262DDDA054AC0C81894E4B07F5BC00970D735843756C08E88967964965BC05C9D393BF7964E40B512811D224A63C052BF600DCF055540C0C4BC3CD1F65FC0E8E262DDDA054AC001030000000100000008000000E8A0B27D65A858C04F7B51E0408551C099174886009155C0A1DB53B0392B54C0445541589EAB5C40E59DCABA6B5848C0C47CB5634AB95840ECB805E5CA903C40F8813E54261A4440FECB62EB2F90544080C4EF0857DC45C09835127EC03C5440C6310A2AAD985FC000B6B4CC24925540E8A0B27D65A858C04F7B51E0408551C0010300000001000000040000007CAA8D7C0B6360C0E7C4D10525B354C054CCA985BE4A474008C64FEDBA2150401D0890D673D95BC0882952E92A5656407CAA8D7C0B6360C0E7C4D10525B354C001030000000100000006000000C031734E7A9B2B40C505B5F2DA2546C0D40177131C455E40DC01275B3AB43DC07CF4D219F51E6440A0F0F88A056417404651EFA2A7684FC0F0B6BF36E5565640B0D6B5748D4466C0802C2A06C52E3A40C031734E7A9B2B40C505B5F2DA2546C00103000000010000000D000000B45737C4E92866C010E76AA1FF8230C0D04BF453301562C019487C0FA61342C031DCB104962366C08ED17448FEA44DC07017345B1D4464C05AE1C2A1288250C0A8700DBE02FE4FC00C08D600044356C0B0211EC704C44E40167D366A1BB647C080007CF9F6BC2C40EEE3E348B4C23EC0E6B18E0D53B6624080FDA8D9E431EFBF006258B53497E3BF50828ED0E77910C089BF397FFD8D5CC05816573FAE84484064453A2A846766C006E26C443B4856409357BC7E845E65C03C51564522AE3540B45737C4E92866C010E76AA1FF8230C00103000000010000000A000000F6D6EACF1E6D64C03A550EABCE8655C08194601319B851C0103717AE3FE04DC0A0D5812B7C9734C0AEAF0FA3B29A52C0584A69958A2C4040343A371ADF0452C054B31393283D64403E46A4AB32674BC060B20A9BC76724C0DCC1632C245D54402E35EA20942852C04480AF8DAE654940BE874612510B58C06079E5BDFD8F0E402B518DB2396461C0E40A92BED6C933C0F6D6EACF1E6D64C03A550EABCE8655C00103000000010000000A00000046EB55492D4258C099C0FC0A375A55C020B2F7BFA6751BC0A49BC44F957445C0FEE78317DD02654008E9137CA33F54C0D41FB0B1F8E151408054476381F834C0D0A0FEEAAA8A58407013983D5C7C15C0E495687B743656408014AC7B824F15C0687E35D7CF7D5F4010E36FE9D6FC1A40F05AF5FB6C5743C004BD6CAB0CCE4040478C72C3C63F66C0589EA28FCC75514046EB55492D4258C099C0FC0A375A55C001030000000100000006000000E8A7C3930DFE3CC0DC29C545CAC94BC040DE27A1A0D802C01C27EC54D2C444C0E8B3EB260EBA3B4060A8895DAE724340607654A9598A2340CE64295790B65040A41167D800D85BC0683052B163A73340E8A7C3930DFE3CC0DC29C545CAC94BC001030000000100000009000000046B8E14D69265C0B0DB9456E86D4BC02E9148C1F8CF61C0078E880A25254AC0F067D9BC3065314030713B877D5D55C0F8A667306AD554403A66A86D813748C0C0098C59809F41C028C9BCBA8AEF3BC0E3266C81B83D52C0EC73F493106B4F401F62ED76DC8856C0B05441A460C61140B99EE00EBE3464C0A8B0C63E987A2340046B8E14D69265C0B0DB9456E86D4BC0':::GEOGRAPHY,e'E\\x04'::VARCHAR);
Running the uniqueness query indicates the values are not equal:
SELECT count(*) FROM (SELECT * FROM schema_w0_16.table_w0_55 WHERE ("col55 _w0_56" + 0.2537466883659363:::FLOAT8) = (SELECT ("col55 _w0_56" + 0.2537466883659363:::FLOAT8) FROM (VALUES (0.0:::FLOAT8)) AS t ("col55 _w0_56")))
count
---------
0
This is linked to floating point precision within the insert versus the comparison. The transaction does see the rows fine, which I initially thought was the problem. Additionally, a comparison query shows similar properties:
SELECT c>d FROM (SELECT ("col55 _w0_56" + 0.2537466883659363:::FLOAT8) as c FROM schema_w0_16.table_w0_55) as A, (SELECT (("col55 _w0_56" + 0.2537466883659363:::FLOAT8)) as d FROM (VALUES (0.0:::FLOAT8)) AS t ("col55 _w0_56")) AS B;
?column?
------------
f
t
t
I was going crazy trying to understand why this doesn't work, but its clear from the plans. When we run with equality we see:
EXPLAIN SELECT count(*) FROM (SELECT * FROM schema_w0_16.table_w0_55 WHERE ("col55 _w0_56" + 0.2537466883659363:::FLOAT8):::FLOAT4 = (SELECT ("col55 _w0_56" + 0.2537466883659363:::FLOAT8) FROM (VALUES
-> (0.0:::FLOAT8)) AS t ("col55 _w0_56"))::FLOAT4)
->
-> ;
info
-----------------------------------------------------------------------------------
distribution: local
vectorized: true
• group (scalar)
│ estimated row count: 1
│
└── • scan
estimated row count: 0 (<0.01% of the table; stats collected 8 hours ago)
table: table_w0_55@table_w0_55_col55 _w0_56_idx
spans: [/0.0 - /0.0]
The optimizer is able to pull 0.2537466883659363 from both sides of the expression above and only looks for col55 _w0_56 containing zero. For integer arithmetic this would be right, but for floating point its possible that because of rounding errors that this isn't true (i.e. col55 _w0_56 + constant, could equal the target value if w0_56 is small enough because of the limits of floating point precision).
If we instead opt for not equal the plan changes and we see:
EXPLAIN SELECT count(*) FROM (SELECT * FROM schema_w0_16.table_w0_55 WHERE ("col55 _w0_56" + 0.2537466883659363:::FLOAT8):::FLOAT4 <> (SELECT ("col55 _w0_56" + 0.2537466883659363:::FLOAT8) FROM (VALUES
-> (0.0:::FLOAT8)) AS t ("col55 _w0_56"))::FLOAT4)
->
-> ;
info
--------------------------------------------------------------------------------
distribution: local
vectorized: true
• group (scalar)
│ estimated row count: 1
│
└── • scan
estimated row count: 2 (67% of the table; stats collected 8 hours ago)
table: table_w0_55@table_w0_55_expr_key
spans: (/NULL - /0.2537466883659362] [/0.25374668836593633 - ]
This produces the correct result because the index on the expression is used, and we scan for values not matching it directly. Let me bug the queries team to see if this is desired behaviour, since selecting the index expression index would also produce the correct result in this case.
pkg/ccl/testccl/workload/schemachange/schemachange_test.TestWorkload failed on release-24.1.2-rc @ 35c3e0c133c56c91399e730f49bc488cf6dd4c11:
Parameters:
attempt=1
run=21
shard=1
Help
See also: How To Investigate a Go Test Failure (internal)
/cc @cockroachdb/sql-foundationsThis test on roachdash | Improve this report!
Jira issue: CRDB-39611