vitessio/vitess · error · ErrUnsupportedTable

table not supported by vexec

Error message

table not supported by vexec

What it means

ErrUnsupportedTable is returned by getPlanner when a vexec statement targets a table other than _vt.vreplication. vexec's planners are table-specific; only the vreplication table has a planner registered, so any other table (including other _vt tables like _vt.schema_migrations) is rejected with this sentinel error.

Source

Thrown at go/vt/vtctl/workflow/vexec/vexec.go:67

)

var ( // Topo lookup errors.
	// ErrNoShardPrimary occurs when a shard is found with no serving
	// primary.
	ErrNoShardPrimary = errors.New("no primary found for shard")
	// ErrNoShardsForKeyspace occurs when attempting to run a vexec on an empty
	// keyspace.
	ErrNoShardsForKeyspace = errors.New("no shards found in keyspace")
)

var ( // Query parsing and planning errors.
	// ErrUnsupportedQuery occurs when attempting to run an unsupported query
	// through vexec.
	ErrUnsupportedQuery = errors.New("query not supported by vexec")
	// ErrUnsupportedTable occurs when attempting to run vexec on an unsupported
	// table. At the time of writing, this occurs when attempting to query any
	// table other than _vt.vreplication.
	ErrUnsupportedTable = errors.New("table not supported by vexec")
)

// VExec provides the main interface to planning and executing vexec queries
// (normally, queries on tables in the `_vt` database). It currently supports
// some limited vreplication queries; this set of supported behavior will expand
// over time. It may be extended to support schema_migrations queries as well.
type VExec struct {
	ts  *topo.Server
	tmc tmclient.TabletManagerClient

	keyspace string
	workflow string

	// (TODO:@ajm188) Consider renaming this field to "targets", and then
	// support different Strategy functions for loading target tablets from a
	// topo.Server.
	//
	// For this, I'm currently thinking:

View on GitHub (pinned to 01a25a7d17)

Solutions

1. Target only _vt.vreplication with vexec for now.
2. For schema_migrations operations, use vtctldclient ApplySchema / MigrationStatus commands instead.
3. For user tables, connect to VTGate and run the query normally rather than through vexec.

Example fix

// before
vexec.Run(ctx, ts, "DELETE FROM _vt.schema_migrations WHERE id=5", "commerce")
// after
// use the dedicated command instead
vtctldclient schema-migration-complete commerce <uuid>

stmt, _ := sqlparser.Parse(q)
table := sqlparser.String(sqlparser.GetTableName(sqlparser.GetFirstSelect stmtTableExpr)) // resolve target table first
if table != "_vt.vreplication" { return fmt.Errorf("vexec only supports _vt.vreplication, got %s", table) }

_, err := vexec.PlanQuery(ctx, ts, keyspace, q)
if errors.Is(err, vexec.ErrUnsupportedTable) {
    // reroute to vtctldclient (ApplySchema etc.) instead of vexec
    return err
}

When it happens

Trigger: Calling vexec.PlanQuery (or running a vexec command) with a statement whose target table is not _vt.vreplication — e.g. 'UPDATE _vt.schema_migrations ...' or a query on a user table.

Common situations: Assuming VExec is a generic proxy for _vt schema queries; trying schema_migrations operations through vexec before that support was added; scripts written against user keyspaces mistakenly routed through vexec.

Related errors

• cannot update immutable column
• unsupported query construct
• attempted to execute unprepared query
• no primary found for shard
• value out of range

AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/43a1ff5e15d06e81. Report an issue: GitHub.