release-21.1: changefeedccl: fail changefeeds when tables go offline #64372
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport 1/1 commits from #64323.
/cc @cockroachdb/release
In 20.2.4, a changefeed would fail if IMPORT INTO was run against one
of its target tables. The failure would look like:
We want changefeed to fail when IMPORT INTO is run because changes via
the AddSSTable mechanism is not currently reflected in the changefeed,
meaning we would fail to emit imported data.
The previous path that raised this failure depended on:
The descriptor being offline at the point we attempted to acquire a
lease on it:
cockroach/pkg/ccl/changefeedccl/schemafeed/schema_feed.go
Line 514 in d196291
The lease acquisition filtering out offline descriptors with an
error:
cockroach/pkg/sql/catalog/descriptor.go
Line 209 in eda2309
The failure from the lease acquisition in the schemafeed being
treated as a fatal error.
I believe our behaviour here has changed a few times on both the 20.2
branch and master because of changes in each of these 3 behaviours.
In this change, rather than relying on the lease acquisition, we
specifically check for offline tables in our ValidateTable
function. This function is called for every descriptor version we get
from the ExportRequest on the Descriptor table.
Currently, I believe that checking for the offline descriptors is
correct since it appears that only restore and import put tables into
an offline state.
Release note (enterprise change): CHANGEFEEDs more reliably fail when
IMPORT INTO is run against a targeted table.
Fixes #64276
See also #62585, #43784