risingwavelabs/risingwave · error · TimeTravel

require SQL meta store

Error message

require SQL meta store

What it means

Time-travel version archival/replay features require a SQL-backed meta store (e.g. PostgreSQL); the in-memory meta store cannot persist time-travel archives. require_sql_meta_store_err returns this Error::TimeTravel whenever a time-travel operation is invoked against a non-SQL store.

Source

Thrown at src/meta/src/hummock/manager/time_travel.rs:870

            "unexpected time travel delta {:?}",
            d
        );
        if d.prev_id < last_version.id {
            return Err(Error::TimeTravel(anyhow!(format!(
                "invalid time travel delta chain: delta {} has prev version {}, but replay has reached {}",
                d.id, d.prev_id, last_version.id
            ))));
        }
        // Compaction deltas are not included in the time travel archive, so there may be gaps
        // between the last replayed version and this delta's previous version.
        last_version.id = d.prev_id;
        last_version.apply_version_delta(&d);
    }
    Ok(last_version)
}

pub fn require_sql_meta_store_err() -> Error {
    Error::TimeTravel(anyhow!("require SQL meta store"))
}

/// Time travel delta replay only expect `NewL0SubLevel`. In all other cases, a new version snapshot should be created.
pub fn should_mark_next_time_travel_version_snapshot(delta: &HummockVersionDelta) -> bool {
    delta.group_deltas.iter().any(|(_, deltas)| {
        deltas
            .group_deltas
            .iter()
            .any(|d| !matches!(d, GroupDeltaCommon::NewL0SubLevel(_)))
    })
}

#[cfg(test)]
mod tests {
    use super::*;

    fn version(id: u64) -> PbHummockVersion {
        let mut version = HummockVersion::default();

View on GitHub (pinned to 6469eb736d)

Solutions

1. Start the cluster with a SQL meta store, e.g. --meta-store postgres (or mysql) with connection details configured.
2. If the in-memory store is intentional, avoid time-travel queries/features on that deployment.
3. Guard feature enablement on Env::meta_store_type being SQL before invoking time-travel APIs.

Example fix

// before: time travel on default in-memory meta store fails
rise CTL "SELECT * FROM t FOR TIMESTAMP AS OF '2024-01-01'";
// after: start meta node with SQL backend
./risedev d # with meta-backend: postgresql in risedev profile
-- or: risingwave meta-node --meta-store postgresql --postgres-host ... 

// Rust: check backend before invoking time travel
if env.meta_store_type() != MetaStoreType::Sql {
    return Err("time travel requires a SQL meta store".into());
}

match time_travel_query(...).await {
    Err(e) if e.to_string().contains("require SQL meta store") =>
        eprintln!("Start the cluster with --meta-store postgres to use time travel"),
    other => other?,
}

When it happens

Trigger: Calling any time-travel query/archive API (e.g. epoch_to_version paths) when the meta store backend is in-memory rather than SQL.

Common situations: Running RisingWave in dev/test with the default in-memory meta backend and then attempting point-in-time queries; docker setups without --meta-store configured to SQL (PostgreSQL/MySQL).

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• invalid time travel delta chain: delta {} has prev version {
• argument `--license-key-path` (or env var `RW_LICENSE_KEY_PA
• should have meta client
• Root directory does not exist: {}
• Cannot find the snapshot id in the iceberg table.

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