What causes "Failed to execute the statement: {0}" in risingwavelabs/risingwave?

Inspect the chained source error (`#[source]`) which contains the actual root cause from the execution engine.

risingwavelabs/risingwave · error · PsqlError

Failed to execute the statement

Error message

Failed to execute the statement: {0}

What it means

Pgwire wraps failures that occur while executing an extended-protocol (prepared statement) Execute step in this variant. The inner BoxedError is the underlying cause, so this message is always a wrapper over a more specific error. It indicates the statement prepared successfully but failed when executed with bound parameters.

Solutions

Inspect the chained source error (`#[source]`) which contains the actual root cause from the execution engine.
Re-run the query with psql to see the un-wrapped error message.
Check parameter types/values bound to the prepared statement match the statement's inferred types.
If the root cause looks like a bug, report it at the RisingWave GitHub issues page.

Example fix

// before: ignoring the cause chain
match err { ... }
// after: unwrap the underlying source
match err {
    PsqlError::ExtendedExecuteError(src) => tracing::error!("execute failed: {:?}", src.source()),
    _ => {}
}

Defensive patterns

Strategy: try-catch

Type guard

fn is_extended_execute_error(e: &PsqlError) -> bool { matches!(e, PsqlError::ExtendedExecuteError(_)) }

Try / catch

match result {
    Err(PsqlError::ExtendedExecuteError(src)) => log_and_surface(src.source()),
    Err(other) => return Err(other),
    Ok(v) => use(v),
}

Prevention

Validate parameter values/types before binding to prepared statements.
Test queries with plain psql first to see un-wrapped errors.
Always log the error source chain, not just the top-level message.

When it happens

Trigger: Calling an extended-query Execute message against RisingWave's pgwire server when the statement fails at runtime (e.g. query planning/execution error, invalid parameter binding, downstream stream/batch engine error surfaced through the BoxedError source).

Common situations: psycopg2/JDBC/go-pq clients using server-side prepared statements; queries that only fail at execute time due to bad parameter values; internal compute errors during query execution.

Understand the failure class

Background: "query failed", "%w: SQL error" — wrapped database query errors in Go libraries explained — this error's family across 3 libraries.

Related errors

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

Appendix: source

Thrown at src/utils/pgwire/src/error.rs:58

        #[backtrace]
        ProtocolViolationError,
    ),

    #[error("Failed to run the query: {0}")]
    SimpleQueryError(
        #[source]
        #[backtrace]
        BoxedError,
    ),

    #[error("Failed to prepare the statement: {0}")]
    ExtendedPrepareError(
        #[source]
        #[backtrace]
        BoxedError,
    ),

    #[error("Failed to execute the statement: {0}")]
    ExtendedExecuteError(
        #[source]
        #[backtrace]
        BoxedError,
    ),

    #[error(transparent)]
    IoError(#[from] IoError),

    /// Uncategorized error for describe, bind.
    #[error(transparent)]
    Uncategorized(
        #[from]
        #[backtrace]
        BoxedError,
    ),

    #[error("Panicked when handling the request: {0}

View on GitHub (pinned to 6469eb736d)