-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[DocDB] [DB Clone] Clone is failing with catalog snapshot invalidated, MISMATCHED_SCHEMA #25929
Closed
1 task done
Labels
area/docdb
YugabyteDB core features
kind/bug
This issue is a bug
priority/medium
Medium priority issue
status/awaiting-triage
Issue awaiting triage
Comments
yamen-haddad
added a commit
that referenced
this issue
Feb 19, 2025
…as of time Summary: Currently, clone is failing when the database has a sequence, and the time we are cloning to is a time before a DDL that increments the last_breaking_version of the source database. Clone is failing in ysql_dump phase when executing the following query to get the sequence data: `SELECT last_value, is_called FROM public.seq_name`. The error is: `ERROR: The catalog snapshot used for this transaction has been invalidated: expected: 2, got: 1: MISMATCHED_SCHEMA`. Generally, ysql_dump sets the GUC `yb_disable_catalog_version_check` to true, which should not set the catalog version in all the read requests that ysql_dump is issuing, and thus no catalog version check is performed. However, as sequences have their own read path, the GUC `yb_disable_catalog_version_check` is not taking effect, and the catalog version check is returning a catalog version mismatch. Fixed by extending the role of `yb_disable_catalog_version_check` to cover the sequences' read path. When set to true, we don't send the catalog version with the read request to the tserver and thus disable the catalog version check for such a sequence read query. This allows ysql_dump to read the sequence as of a time regardless of the catalog version at that time and thus, being able to clone sequences to a time before a DDL happened. Jira: DB-15245 Test Plan: ./yb_build.sh --cxx-test integration-tests_minicluster-snapshot-test --gtest_filter Colocation/PgCloneTestWithColocatedDBParam.CloneWithSequencesAndDdl/0 Reviewers: asrivastava Reviewed By: asrivastava Subscribers: ybase, yql, slingam Differential Revision: https://phorge.dev.yugabyte.com/D41911
vaibhav-yb
pushed a commit
to vaibhav-yb/yugabyte-db
that referenced
this issue
Feb 20, 2025
…quences as of time Summary: Currently, clone is failing when the database has a sequence, and the time we are cloning to is a time before a DDL that increments the last_breaking_version of the source database. Clone is failing in ysql_dump phase when executing the following query to get the sequence data: `SELECT last_value, is_called FROM public.seq_name`. The error is: `ERROR: The catalog snapshot used for this transaction has been invalidated: expected: 2, got: 1: MISMATCHED_SCHEMA`. Generally, ysql_dump sets the GUC `yb_disable_catalog_version_check` to true, which should not set the catalog version in all the read requests that ysql_dump is issuing, and thus no catalog version check is performed. However, as sequences have their own read path, the GUC `yb_disable_catalog_version_check` is not taking effect, and the catalog version check is returning a catalog version mismatch. Fixed by extending the role of `yb_disable_catalog_version_check` to cover the sequences' read path. When set to true, we don't send the catalog version with the read request to the tserver and thus disable the catalog version check for such a sequence read query. This allows ysql_dump to read the sequence as of a time regardless of the catalog version at that time and thus, being able to clone sequences to a time before a DDL happened. Jira: DB-15245 Test Plan: ./yb_build.sh --cxx-test integration-tests_minicluster-snapshot-test --gtest_filter Colocation/PgCloneTestWithColocatedDBParam.CloneWithSequencesAndDdl/0 Reviewers: asrivastava Reviewed By: asrivastava Subscribers: ybase, yql, slingam Differential Revision: https://phorge.dev.yugabyte.com/D41911
yamen-haddad
added a commit
that referenced
this issue
Mar 24, 2025
…eading sequences as of time Summary: Original commit: 7fc910d / D41911 Currently, clone is failing when the database has a sequence, and the time we are cloning to is a time before a DDL that increments the last_breaking_version of the source database. Clone is failing in ysql_dump phase when executing the following query to get the sequence data: `SELECT last_value, is_called FROM public.seq_name`. The error is: `ERROR: The catalog snapshot used for this transaction has been invalidated: expected: 2, got: 1: MISMATCHED_SCHEMA`. Generally, ysql_dump sets the GUC `yb_disable_catalog_version_check` to true, which should not set the catalog version in all the read requests that ysql_dump is issuing, and thus no catalog version check is performed. However, as sequences have their own read path, the GUC `yb_disable_catalog_version_check` is not taking effect, and the catalog version check is returning a catalog version mismatch. Fixed by extending the role of `yb_disable_catalog_version_check` to cover the sequences' read path. When set to true, we don't send the catalog version with the read request to the tserver and thus disable the catalog version check for such a sequence read query. This allows ysql_dump to read the sequence as of a time regardless of the catalog version at that time and thus, being able to clone sequences to a time before a DDL happened. Jira: DB-15245 Test Plan: ./yb_build.sh --cxx-test integration-tests_minicluster-snapshot-test --gtest_filter Colocation/PgCloneTestWithColocatedDBParam.CloneWithSequencesAndDdl/0 Reviewers: asrivastava Reviewed By: asrivastava Subscribers: slingam, yql, ybase Differential Revision: https://phorge.dev.yugabyte.com/D42696
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/docdb
YugabyteDB core features
kind/bug
This issue is a bug
priority/medium
Medium priority issue
status/awaiting-triage
Issue awaiting triage
Jira Link: DB-15245
Description
Description:
Version: 2.25.1.0-b280
Steps:
Clone doesn't go through with following Error:
Minimal repro thanks to @yamen-haddad
Issue Type
kind/bug
Warning: Please confirm that this issue does not contain any sensitive information
The text was updated successfully, but these errors were encountered: