tursodatabase/turso · critical

{name} virtual table creation should not fail

Error message

{name} virtual table creation should not fail

What it means

The PostgreSQL frontend builds its static catalog (pg_tables, pg_class, etc.) by constructing VirtualTables from hardcoded module definitions via VirtualTable::new_internal and asserts success — the embedded CREATE SQL and module registration are expected to always parse and construct. The panic means one of the built-in catalog vtabs failed to construct: the shipped SQL/constructor is incompatible with the current parser or vtab API. It aborts frontend startup.

Source

Thrown at postgres/frontend/catalog.rs:1510

        _idx_num: i32,
    ) -> Result<bool, LimboError> {
        Ok(false)
    }
}

fn empty_catalog_table(name: &str, create_sql: &str) -> Arc<VirtualTable> {
    let table = EmptyPgCatalogTable {
        name: name.to_string(),
        create_sql: create_sql.to_string(),
    };
    Arc::new(
        VirtualTable::new_internal(
            name.to_string(),
            table.sql(),
            VTabKind::VirtualTable,
            Arc::new(RwLock::new(table)),
        )
        .unwrap_or_else(|_| panic!("{name} virtual table creation should not fail")),
    )
}

/// Virtual table implementation for pg_tables
/// Maps user tables to PostgreSQL's pg_tables view
#[derive(Debug)]
pub struct PgTablesTable;

impl PgTablesTable {
    pub fn new() -> Self {
        Self
    }
}

impl InternalVirtualTable for PgTablesTable {
    fn name(&self) -> String {
        "pg_tables".to_string()
    }

View on GitHub (pinned to 244cde92a7)

Solutions

1. Do a clean full-workspace build (cargo clean && cargo build) to rule out stale artifacts and version skew
2. Report immediately with the exact commit and feature flags — a stock build must start; include the catalog table name from the panic
3. Verify the feature set used for the postgres frontend matches CI; drop experimental combos
4. If maintaining a fork, replace unwrap_or_else(panic) temporarily to print the underlying error from new_internal and fix that mismatch

Example fix

// contributor fix: surface the real cause instead of a bare assertion
let table = VirtualTable::new_internal(
    name.to_string(),
    table.sql(),
    VTabKind::VirtualTable,
    Arc::new(RwLock::new(table)),
)
.unwrap_or_else(|e| panic!("{name} virtual table creation failed: {e:?}"));

// startup smoke test: every built-in catalog vtab must construct before serving traffic
#[test]
fn pg_catalog_tables_construct() {
    for (name, sql) in builtin_catalog_definitions() {
        let module = empty_module_for(name);
        assert!(
            VirtualTable::new_internal(name.into(), sql, VTabKind::VirtualTable, module).is_ok(),
            "catalog table {name} failed to construct"
        );
    }
}

// isolate catalog init so a failure is a diagnosable startup error, not a raw panic
catalog = std::panic::catch_unwind(build_catalog)
    .map_err(|payload| format!("pg catalog init failed: {payload:?}"))?;

When it happens

Trigger: Starting the postgres-frontend server in a build where VirtualTable::new_internal rejects a catalog table's SQL — version skew between postgres/frontend/catalog.rs and the parser/extensions, stale partial builds, or feature-flag combinations (e.g. cli_only) changing vtab registration behavior.

Common situations: Partial or mixed-version workspace builds; forks that modified the parser grammar or VirtualTable::new_internal; experimental feature combos not covered by CI.

Related errors

• Pool not initialized
• OpenRead on virtual table cursor, use Insn:VOpen instead
• VOpen on non-virtual table cursor
• VUpdate on non-virtual table cursor
• Insn:Column on virtual table cursor, use Insn:VColumn instea

AI-assisted analysis of tursodatabase/turso@244cde92a7 (2026-08-20). Data as JSON: /api/errors/bab115facb4fb551. Report an issue: GitHub.