This issue was identified while investigating #106648. The test in this draft PR reliably reproduces the bug #106761.

The crdb_internal.jobs virtual table uses version gates to determine if the 'job_type' backfill has run. The problem is if a query is executed with an AS OF SYSTEM TIME clause that picks a transaction timestamp before the job_type migration, then crdb_internal.jobs will attempt to query the job_type column even though it doesn't exist at the transaction's timestamp.

My first thought for how to fix this is to have the crdb_internal.jobs virtual table consult the state of the descriptor instead of the state of the version when constructing the query. But that doesn't work, because the correct query depends on the state of the backfill, not the existence of the job_type column in the descriptor. Since the query should only read the job_type column after the backfill completes.

This is similar to an issue that I identified when working on the RBR system table migrations. I wrote a utility for reading the cluster version in a transaction. But I'm realizing now that the optimization in version guard to skip reading the version setting after the migration completes depends on query serializability and is broken if used within the context of an AS OF SYSTEM TIME transaction. That's actually okay for the current callers because it's only used by internal queries that do not use AS OF SYSTEM TIME, but it means we can't use it to fix the issue with the crdb_internal.jobs virtual table.

Jira issue: CRDB-29706