Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crosscluster/logical: ldr cannot support replicating tables with indexes that conduct expression evaluation on write path #133560

Open
msbutler opened this issue Oct 28, 2024 · 1 comment
Labels
A-disaster-recovery C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) docs-known-limitation T-disaster-recovery

Comments

@msbutler
Copy link
Collaborator

msbutler commented Oct 28, 2024

A (hopefully) complete list of table schema we cannot support:

  • No hash sharded index
  • No partial Indexes
  • If a table contains a virtual computed column, we cannot support:
  • A secondary index whose key contains the computed column
  • A secondary index with a storing computed column (see). Note, if the computed column is stored in the pk, we can support the above.

The immediate mode write path does not understand how to evaluate expressions. The writer we currently use simply expects the full set of columns to be given to, even the computed ones, along with a list of columns that we've already determined should be updated. Note: we could, in theory, support these on the validated mode write path, but if we did, the schema change validation logic below would need to know which Job is in immediate mode vs validated mode. So to simplify schema change validation in 24.3, we should disallow these class of schema all together in LDR.

Computed column example: consider a table with two integer columns v1 and v2 and a third virtual column v3 defined as v1 and v2. If you created a secondary index on the virtual column v3, then suddenly you need to evaluate the expression v1 + v2 in order to create the index entry for v3. If the virtual column happens to be STORED then we could support it because then we will see the result of the source-side evaluation in the stored column that appears on the rangefeed.

Partial index example: When you have a partial index, you have to evaluate the expression to see if that index should be updated. For instance, you might have an index CREATE INDEX ON t (a, b) WHERE c > 5; that requires you to check if c is greater than 5 before you create in index entry for it.

Jira issue: CRDB-43687

@msbutler msbutler added C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) docs-known-limitation T-disaster-recovery labels Oct 28, 2024
Copy link

blathers-crl bot commented Oct 28, 2024

cc @cockroachdb/disaster-recovery

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-disaster-recovery C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) docs-known-limitation T-disaster-recovery
Projects
None yet
Development

No branches or pull requests

1 participant