risingwavelabs/risingwave · error · SessionConfigError

Unrecognized config entry `{0}`

Error message

Unrecognized config entry `{0}`

What it means

SessionConfigError variant fired when a SET/show-style configuration key does not match any known session config entry. It is a validation guard on user-supplied config names: any key not registered in the session config map (a typo or a Postgres-only variable RisingWave does not support) triggers it.

Source

Thrown at src/common/src/session_config/mod.rs:61

use crate::hash::VirtualNode;
use crate::session_config::parallelism::{ConfigBackfillParallelism, ConfigParallelism};
use crate::session_config::sink_decouple::SinkDecouple;
use crate::session_config::transaction_isolation_level::IsolationLevel;
pub use crate::session_config::visibility_mode::VisibilityMode;
use crate::{PG_VERSION, SERVER_ENCODING, SERVER_VERSION_NUM, STANDARD_CONFORMING_STRINGS};

pub const SESSION_CONFIG_LIST_SEP: &str = ", ";

#[derive(Error, Debug)]
pub enum SessionConfigError {
    #[error("Invalid value `{value}` for `{entry}`")]
    InvalidValue {
        entry: &'static str,
        value: String,
        source: anyhow::Error,
    },

    #[error("Unrecognized config entry `{0}`")]
    UnrecognizedEntry(String),
}

type SessionConfigResult<T> = std::result::Result<T, SessionConfigError>;

const AUTO_LOCALITY_BACKFILL_MIN_SIZE: u64 = 10 * 1024 * 1024 * 1024;

fn default_auto_locality_backfill_min_size() -> u64 {
    AUTO_LOCALITY_BACKFILL_MIN_SIZE
}

fn default_legacy_locality_backfill_mode() -> LocalityBackfillMode {
    LocalityBackfillMode::Always
}

// NOTE(kwannoel): We declare it separately as a constant,
// otherwise seems like it can't infer the type of -1 when written inline.
const DISABLE_BACKFILL_RATE_LIMIT: i32 = -1;

View on GitHub (pinned to 6469eb736d)

Solutions

1. Check RisingWave's supported session config list and use only recognized entry names.
2. Fix the typo in the entry name (entry names are case-insensitive but must match exactly otherwise).
3. Remove the SET/SHOW/RESET for unsupported Postgres GUCs, or guard them client-side.
4. If the GUC should exist, implement it in the session config module.

Example fix

-- before
SET synchronous_commit = off;
-- after (remove unsupported GUC or use supported alternative)
-- no-op: synchronous_commit not supported in RisingWave

const KNOWN_GUCS = new Set(['search_path','server_version','timezone','server_encoding']);
if (!KNOWN_GUCS.has(entry.toLowerCase())) throw new Error(`unsupported GUC ${entry}`);

match session.set_config(entry, value) {
    Err(SessionConfigError::UnrecognizedEntry(name)) =>
        eprintln!("skipping unsupported setting: {name}"),
    Err(e) => return Err(e.into()),
    Ok(_) => {}
}

When it happens

Trigger: Running `SET <unknown_entry> = <value>`, `SHOW <unknown_entry>`, or `RESET <unknown_entry>` (via the session config lookup) with an identifier not in RisingWave's supported config list.

Common situations: Porting Postgres applications that set GUCs RisingWave does not implement (e.g. `SET synchronous_commit`); typos in GUC names; tooling auto-configuring sessions with unsupported parameters.

Related errors

• Invalid value `{value}` for `{entry}`
• query_epoch not set in distributed lookup join
• Join key types are not aligned: LHS: {outer_type:?}, RHS: {i
• Join key types are not aligned: LHS: {outer_type:?}, RHS: {i
• Row sequential scan should not have input executor!

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