{"record":{"id":"e15cb443f0d4e892","repo":"vitessio/vitess","slug":"primary-key-column-v-not-found-in-table-s-select","errorCode":null,"errorMessage":"primary key column %v not found in table's select filter or the TableMap event within the GTID","messagePattern":"primary key column (.+?) not found in table's select filter or the TableMap event within the GTID","errorType":"validation","errorClass":null,"httpStatus":null,"severity":"error","filePath":"go/vt/vttablet/tabletmanager/vreplication/table_plan_builder.go","lineNumber":610,"sourceCode":"// Input cols should be ordered according to key ordinal.\n// e.g. if \"UNIQUE KEY(c5,c2)\" then we expect c5 to come before c2\nfunc (tpb *tablePlanBuilder) analyzePK(cols []*ColumnInfo) error {\n\tfor _, col := range cols {\n\t\tif !col.IsPK {\n\t\t\tcontinue\n\t\t}\n\t\tif col.IsGenerated {\n\t\t\t// It's possible that a GENERATED column is part of the PRIMARY KEY. That's valid.\n\t\t\t// But then, we also know that we don't actually SELECT a GENERATED column, we just skip\n\t\t\t// it silently and let it re-materialize by MySQL itself on the target.\n\t\t\tcontinue\n\t\t}\n\t\tcexpr := tpb.findCol(sqlparser.NewIdentifierCI(col.Name))\n\t\tif cexpr == nil {\n\t\t\t// TODO(shlomi): at some point in the futue we want to make this check stricter.\n\t\t\t// We could be reading a generated column c1 which in turn selects some other column c2.\n\t\t\t// We will want t oensure that `c2` is found in select list...\n\t\t\treturn fmt.Errorf(\"primary key column %v not found in table's select filter or the TableMap event within the GTID\", col)\n\t\t}\n\t\tif cexpr.operation != opExpr {\n\t\t\treturn fmt.Errorf(\"primary key column %v is not allowed to reference an aggregate expression\", col)\n\t\t}\n\t\tcexpr.isPK = true\n\t\tcexpr.dataType = col.DataType\n\t\tcexpr.columnType = col.ColumnType\n\t\ttpb.pkCols = append(tpb.pkCols, cexpr)\n\t}\n\treturn nil\n}\n\n// analyzeExtraSourcePkCols builds tpb.extraSourcePkCols.\n// VReplication allows source and target tables to use different unique keys. Normally, both will\n// use same PRIMARY KEY. Other times, same other UNIQUE KEY. But it's possible that source and target\n// unique keys will only have partial (or empty) shared list of columns.\n// To be able to generate UPDATE/DELETE queries correctly, we need to know the identities of the\n// source unique key columns, that are not already part of the target unique key columns. We call","sourceCodeStart":592,"sourceCodeEnd":628,"githubUrl":"https://github.com/vitessio/vitess/blob/01a25a7d176f94613b8d59d799f438380a8760e4/go/vt/vttablet/tabletmanager/vreplication/table_plan_builder.go#L592-L628","documentation":"During vreplication copy-phase plan construction, analyzePK validates that every primary key column of the source table appears in the table's select filter (or is resolvable from the TableMap event within the GTID). If findCol cannot match a PK column to a select expression, the plan cannot reliably identify rows being copied, so it fails fast. This guards against misconfigured Filter select expressions (e.g. filtered/generated column lists that omit a PK column).","triggerScenarios":"A MoveTables/Reshard workflow whose Filter rule contains a select expression for a table that does not include all of that table's primary key columns (e.g. SELECT of a subset of columns, or a generated column whose underlying column is not selected).","commonSituations":"Users restrict copied columns via filter 'select' expressions but forget the PK column; schema changed to add a PK column after the filter was written; PK is a generated column referencing a non-selected column.","solutions":["Add the missing primary key column to the Filter rule's select expression so analyzePK can resolve it","Verify the table's PK via SHOW CREATE TABLE and ensure every PK column is present in the select list","If the PK is a generated column, also select the column(s) it derives from","Recreate/reload the workflow with the corrected filter"],"exampleFix":"// before: filter select omits PK\n\"select id_hash from t\"\n// after: include the PK column\n\"select id, id_hash from t\"","handlingStrategy":"validation","validationCode":"// Before starting the workflow, verify every PK column appears in the filter select\nSHOW CREATE TABLE t; -- list PK columns\n-- ensure each PK column appears in the Filter rule's \"select\" expression","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Always include all PK columns in filter select expressions","Re-validate filters after any source schema/PK change","Test the filter on a scratch workflow before production MoveTables","For generated-column PKs, also select their source columns"],"tags":["vreplication","copy-phase","plan-builder","primary-key"],"backgroundTag":"pk-column-missing-from-select-filter","analyzedSha":"01a25a7d176f94613b8d59d799f438380a8760e4","analyzedAt":"2026-09-01T17:28:30.605Z","contentChangedAt":null,"schemaVersion":2},"datasetVersion":"2026-09-08T10:18:20.063Z"}