cannot derive generated columns or the `_rw_timestamp`…

Error message

cannot derive generated columns or the `_rw_timestamp` system column in a sink catalog, but found one

What it means

`gen_sink_plan` hits an `unreachable!` when, for a sink targeting an internal table, the derived sink catalog contains a column that cannot be DML'd — a generated column or the `_rw_timestamp` system column. Sink catalogs are supposed to contain only real, writable columns because sinks only insert derived values; presence of a generated/system column means the catalog derivation produced something unexpected.

Solutions

Remove generated columns from the target table, or sink into a table without generated columns.
Filter sink columns explicitly (`CREATE SINK ... AS SELECT <only base columns>`) instead of `FROM t` style all-column sinks.
Upgrade RisingWave — later versions handle generated/system columns in sink catalogs more gracefully.
Internal fix: skip non-DML columns in sink catalog derivation rather than unreachable!.

Example fix

// before
CREATE SINK s FROM t INTO target_table; -- target_table has generated column gc
// after
CREATE SINK s AS SELECT id, payload FROM t; -- exclude generated columns

Defensive patterns

Strategy: validation

Validate before calling

-- ensure the target table has no generated columns before sinking into it
SELECT column_name, is_generated
FROM information_schema.columns
WHERE table_name = 'target_table' AND is_generated = 'ALWAYS';

Prevention

Sink into tables without generated columns, or use explicit column lists in the sink query.
Prefer `CREATE SINK ... AS SELECT <cols>` over `FROM t` sinks to control the schema.
Re-check target table DDL after any ALTER before creating sinks.

When it happens

Trigger: Creating a sink whose downstream target table (via `target_table_catalog`) has the sink catalog derivation (`derive_sink_catalog`) yield generated columns or `_rw_timestamp` — e.g. sinking into a table with generated columns where the sink-from-table path picks up those columns.

Common situations: `CREATE SINK s FROM t INTO target_table` where `target_table` contains generated columns or was altered to add `_rw_timestamp`; planner regressions after adding new hidden column kinds that forgot to update `can_dml` handling.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/f37683df8463b7bb. Report an issue: GitHub.

Appendix: source

Thrown at src/frontend/src/handler/create_sink.rs:544

            .chain(
                dependent_secrets
                    .iter()
                    .copied()
                    .map(|id| id.as_object_id()),
            )
            .collect();

    let sink_catalog = sink_desc.into_catalog(
        sink_schema_id,
        sink_database_id,
        session.user_id(),
        connector_conn_ref,
    );

    if let Some(table_catalog) = &target_table_catalog {
        for column in sink_catalog.full_columns() {
            if !column.can_dml() {
                unreachable!(
                    "cannot derive generated columns or the `_rw_timestamp` system column in a sink catalog, but found one"
                );
            }
        }

        let table_columns_without_rw_timestamp = table_catalog.columns_without_rw_timestamp();
        let exprs = derive_default_column_project_for_sink(
            &sink_catalog,
            sink_plan.schema(),
            &table_columns_without_rw_timestamp,
            user_specified_columns,
        )?;

        let logical_project = generic::Project::new(exprs, sink_plan);

        sink_plan = StreamProject::new(logical_project).into();

        let exprs = LogicalSource::derive_output_exprs_from_generated_columns(

View on GitHub (pinned to 6469eb736d)