roachtest: sqlsmith cannot use tuple on datumVec of type unknown

[cockroach-teamcity]

(roachtest).sqlsmith/setup=seed/setting=no-mutations failed on master@171cc86d6d84c110197485b5d886d77cddc12399:

The test failed on branch=master, cloud=gce:
test artifacts and logs in: /home/agent/work/.go/src/github.com/cockroachdb/cockroach/artifacts/sqlsmith/setup=seed/setting=no-mutations/run_1
	sqlsmith.go:198,sqlsmith.go:228,test_runner.go:767: error: pq: internal error: cannot use value of type tuple{oid, timestamptz, bytes} on a datumVec of type unknown
		stmt:
		WITH
			with_3311 (col_19774)
				AS (
					SELECT
						*
					FROM
						(
							VALUES
								(
									(
										SELECT
											NULL AS col_19773
										FROM
											defaultdb.public.seed@seed__int8__float8__date_idx AS tab_7977
										ORDER BY
											tab_7977._float4
										LIMIT
											1:::INT8
									)
								)
						)
							AS tab_7978 (col_19774)
					UNION
						SELECT
							*
						FROM
							(
								VALUES
									(
										COALESCE(
											(185351876:::OID, '2006-04-21 02:50:20.000257+00:00':::TIMESTAMPTZ, '\x00':::BYTES),
											(314839184:::OID, '1990-10-10 09:04:36.000503+00:00':::TIMESTAMPTZ, '\x21':::BYTES)
										)
									),
									((3901000074:::OID, '1985-06-09 06:19:47.000198+00:00':::TIMESTAMPTZ, '\x764064':::BYTES)),
									((3116072174:::OID, '1993-04-16 05:14:06.000015+00:00':::TIMESTAMPTZ, '\x15a3b1':::BYTES)),
									(
										(2416637916:::OID, '2012-05-13 20:22:26.00034+00:00':::TIMESTAMPTZ, '\x71b859026fb9':::BYTES)
									)
							)
								AS tab_7979 (col_19775)
				)
		SELECT
			(NULL, '2015-12-13 16:14:45.00086+00:00':::TIMESTAMPTZ, '\x7fa0ad092d268f57d7':::BYTES) AS col_19776
		FROM
			with_3311 AS cte_ref_939;

More

Artifacts: /sqlsmith/setup=seed/setting=no-mutations

See this test on roachdash
_{powered by pkg/cmd/internal/issues}

[yuzefovich]

Seems related to #59148.

[yuzefovich]

Reduced repro:

CREATE TABLE t (a INT); INSERT INTO t VALUES (1);

WITH
  cte (cte_col)
    AS (
      SELECT
        *
      FROM
        (VALUES ((SELECT NULL FROM t LIMIT 1:::INT8)))
      UNION SELECT * FROM (VALUES ((1, 2)))
    )
SELECT
  NULL
FROM
  cte;

I think it is the same problem as #59148, so I'll close it as a duplicate.

[RaduBerinde]

Hi Yahor,

I am working on #59148 and my fix doesn't solve this case. I believe it's a different problem. This is the optimizer plan, edited to keep only the relevant parts:

  project
   ├── columns: "?column?":11(unknown)
   ├── union
   │    ├── columns: column1:9(tuple{int, int})
   │    ├── left columns: column1:8(tuple{int, int})
   │    ├── right columns: column1:7(tuple{int, int})
   │    ├── project
   │    │    ├── columns: column1:8(tuple{int, int})
   │    │    ├── values
   │    │    │    ├── columns: column1:6(unknown)
   │    │    │    └── tuple [type=tuple{unknown}]
   │    │    │         └── subquery [type=unknown]
   │    │    │              └── project
   │    │    │                   ├── columns: "?column?":5(unknown)
   │    │    │                   ├── scan t
   │    │    │                   │    ├── limit: 1
   │    │    │                   │    ├── stats: [rows=1]
   │    │    │                   │    ├── cost: 5.05
   │    │    │                   │    └── key: ()
   │    │    │                   └── projections
   │    │    │                        └── null [as="?column?":5, type=unknown]
   │    │    └── projections
   │    │         └── cast:  [as=column1:8, type=tuple{int, int}, outer=(6), immutable]
   │    │              └── variable: column1:6 [type=unknown]
   │    └── values
   │         ├── columns: column1:7(tuple{int, int})
   │         └── tuple [type=tuple{tuple{int, int}}]
   │              └── tuple [type=tuple{int, int}]
   │                   ├── const: 1 [type=int]
   │                   └── const: 2 [type=int]
   └── projections
        └── null [as="?column?":11, type=unknown]

The plan does cast the NULL to tuple{int, int}. Is it possible that on the execution side we don't support these types of casts? For one, we can't really serialize them for distsql (I believe there's an issue open about that). That's why it also doesn't show up right in the plan (type missing in cast: ). As a stop-gap, we could throw out an error any time we try to execbuild a cast to tuple.

[yuzefovich]

Thanks, I'll take a closer look.

Yeah, we definitely don't support such a cast "natively" in the vectorized engine, but we should be able to wrap a noop rowexec processor with the appropriate post-processing spec into the vectorized flow to handle such case. Possibly the root cause is the serialization issue you mentioned.