qrep: derive pull columns from source instead of catalog schema

[dtunikov]

Problem

QRep pulls with excluded columns or child-table range partitions fail with:

[qrep] failed to pull records: failed to load table schema: no rows in result set

The pull path (qrep_source.go) built the SELECT column list by loading the table schema from table_schema_mapping, keyed by (ParentMirrorName, DestinationTableIdentifier). When no row exists for that key, QueryRow().Scan() returns pgx.ErrNoRows ("no rows in result set") and the pull hard-fails.

This has been observed on a CDC mirror. The in-repo setup paths normally populate that row under a matching key, so the exact reason the row was absent for this mirror isn't pinned down (candidates: version skew / older mirror, or attaching to a pre-existing mirror). Regardless, the pull shouldn't depend on the catalog row being present when it can derive the columns directly from the source.

Fix

Derive the column list directly from the source via GetSelectedColumns (which reads pg_attribute) — the same primitive getTableSchemaForTable already uses to build the identical list, so column selection and ordering are unchanged.

This removes the table_schema_mapping dependency from the pull path entirely. catalogPool is no longer needed by corePullQRepRecords.

🤖 Generated with Claude Code

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[Copilot]

Pull request overview

Removes QRep pull-time dependence on table_schema_mapping by deriving the SELECT column list directly from the source table (via pg_attribute), preventing pulls from hard-failing when the catalog schema row is missing.

Changes:

• Stop loading table schema from the catalog for building the SELECT column list during QRep pulls.
• Derive selected columns from the source table using GetSelectedColumns when excludes or child-table range partitions are involved.
• Drop catalogPool usage from corePullQRepRecords (callers keep the parameter but ignore it).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dtunikov]

optional, suggested by copilot to keep columns order consistent across calls

[ilidemi]

Would prefer to first understand what led to the error before making a change just in case. What if there's a consistency issue

[dtunikov]

@ilidemi

Would prefer to first understand what led to the error before making a change just in case. What if there's a consistency issue.

I explained it in internal discussion, posting here as well:
this is what has happened most probably:

• Resync cancels the active snapshot/QRep children.
• DropFlowWorkflow deletes all table_schema_mapping rows, including during resync.
• An already-running QRep pull gets far enough to perform this new schema lookup before its cancellation is observed.
• It sees the deleted row and emits this exact error.

[ilidemi]

Ah right, I missed that thread. Conceptually having a single source of truth is nicer, and waiting on full Temporal cancellation before starting resync would be a cleaner fix (if possible), but this is also bringing us closer to not needing an overarching snapshot tx and still supporting schema changes so ok enough.