Jira Link: DB-22405
Description
schemadiff.chooseMatchKeys (yb-voyager/src/schemadiff/match.go) decides whether to match tables/columns across two snapshots by stable catalog ID (so a rename is detected as a rename) or by name (so a rename reads as drop+add). It currently ID-matches when:
dbTypeA == dbTypeB && (engine is Postgres or YugabyteDB)
dbTypeA == dbTypeB is a proxy for "same system," and it is too loose. Two different servers of the same engine (e.g. a source Postgres and a target Postgres) have independent OID spaces — the same logical table can be pg_class.oid 500 on one and 731 on the other. Matching by ID across them would fail to pair the tables and report the entire schema as drop+add.
This is safe today because detect-drift v1 only ever diffs snapshots of the same source instance over time (same OID space), so dbTypeA == dbTypeB implies same-instance in practice. The gap opens as soon as we diff across instances — e.g. source↔target schema comparison.
Why it's deferred: the discriminator we actually need is the snapshot's Side/instance identity, which lives in schemasnapshot.SnapshotHeader. Diff today receives only SnapshotContent (no header), so tightening the predicate requires plumbing a same-instance signal into the diff path.
Scope / proposed approach:
- Plumb a same-instance / Side (or instance) identity from SnapshotHeader into Diff (either pass it alongside SnapshotContent, or pass the full SchemaSnapshot).
- Change the chooseMatchKeys predicate from "same engine + PG/YB" to "same instance + PG/YB".
- Cross-instance (or differing-instance) diffs then correctly fall back to name matching.
Issue Type
kind/enhancement
Warning: Please confirm that this issue does not contain any sensitive information
Jira Link: DB-22405
Description
schemadiff.chooseMatchKeys (yb-voyager/src/schemadiff/match.go) decides whether to match tables/columns across two snapshots by stable catalog ID (so a rename is detected as a rename) or by name (so a rename reads as drop+add). It currently ID-matches when:
dbTypeA == dbTypeB && (engine is Postgres or YugabyteDB)
dbTypeA == dbTypeB is a proxy for "same system," and it is too loose. Two different servers of the same engine (e.g. a source Postgres and a target Postgres) have independent OID spaces — the same logical table can be pg_class.oid 500 on one and 731 on the other. Matching by ID across them would fail to pair the tables and report the entire schema as drop+add.
This is safe today because detect-drift v1 only ever diffs snapshots of the same source instance over time (same OID space), so dbTypeA == dbTypeB implies same-instance in practice. The gap opens as soon as we diff across instances — e.g. source↔target schema comparison.
Why it's deferred: the discriminator we actually need is the snapshot's Side/instance identity, which lives in schemasnapshot.SnapshotHeader. Diff today receives only SnapshotContent (no header), so tightening the predicate requires plumbing a same-instance signal into the diff path.
Scope / proposed approach:
Issue Type
kind/enhancement
Warning: Please confirm that this issue does not contain any sensitive information