risingwavelabs/risingwave · error · ExprError

Numeric out of range: underflow

Error message

Numeric out of range: underflow

What it means

ExprError::NumericUnderflow is raised when a numeric operation or cast produces a value below the minimum representable value of the target type — i.e. an underflow, reported distinctly from overflow.

Source

Thrown at src/expr/core/src/error.rs:61

    /// A collection of multiple errors in batch evaluation.
    #[error("multiple errors:\n{1}")]
    Multiple(ArrayRef, MultiExprError),

    // Ideally "Unsupported" errors are caught by frontend. But when the match arms between
    // frontend and backend are inconsistent, we do not panic with `unreachable!`.
    #[error("Unsupported function: {0}")]
    UnsupportedFunction(String),

    #[error("Unsupported cast: {0} to {1}")]
    UnsupportedCast(DataType, DataType),

    #[error("Casting to {0} out of range")]
    CastOutOfRange(&'static str),

    #[error("Numeric out of range")]
    NumericOutOfRange,

    #[error("Numeric out of range: underflow")]
    NumericUnderflow,

    #[error("Numeric out of range: overflow")]
    NumericOverflow,

    #[error("Division by zero")]
    DivisionByZero,

    #[error("Parse error: {0}")]
    // TODO(error-handling): should prefer use error types than strings.
    Parse(Box<str>),

    #[error("Invalid parameter {name}: {reason}")]
    // TODO(error-handling): should prefer use error types than strings.
    InvalidParam {
        name: &'static str,
        reason: Box<str>,
    },

View on GitHub (pinned to 6469eb736d)

Solutions

1. Use a wider target type for the operation or cast
2. Clamp inputs to a safe range before computing
3. Use try_cast to convert failures into NULL
4. Investigate the offending input rows from query context

Example fix

// before
SELECT col::real FROM t; -- value below real min
// after
SELECT try_cast(col as real) FROM t;

// pre-check lower bound before narrowing
if v < min_allowed { /* clamp or NULL before cast */ }

match eval_result {
    Err(e) if e.to_string().contains("underflow") => {
        // widen type or clamp to min representable value
    }
    r => r,
}

When it happens

Trigger: Evaluating arithmetic (e.g. multiplying two very small-magnitude numerics/negatives) or narrowing casts where the result is below the target type's lower bound.

Common situations: Casting large negative numerics to narrow signed types; repeated division/multiplication driving values to extremes; financial data with tiny decimal scales.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

• Numeric out of range
• Numeric out of range: overflow
• event offset is too big, offset: {}
• Division by zero
• query_epoch not set in distributed lookup join

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