-
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
[Phase 1][colocation] Set colocation_id consistently in schemas #5017
Labels
area/ysql
Yugabyte SQL (YSQL)
kind/enhancement
This is an enhancement of an existing feature
priority/medium
Medium priority issue
Comments
jaki
added
kind/enhancement
This is an enhancement of an existing feature
area/ysql
Yugabyte SQL (YSQL)
labels
Jul 8, 2020
tverona1
changed the title
[colocation] Set pgtable_id consistently in schemas
[Phase 1][colocation] Set pgtable_id consistently in schemas
May 17, 2022
yugabyte-ci
added
kind/bug
This issue is a bug
and removed
kind/enhancement
This is an enhancement of an existing feature
labels
Jun 9, 2022
yugabyte-ci
added
kind/enhancement
This is an enhancement of an existing feature
and removed
kind/bug
This issue is a bug
labels
Jul 9, 2022
yugabyte-ci
changed the title
[Phase 1][colocation] Set pgtable_id consistently in schemas
[Phase 1][colocation] Set colocation_id consistently in schemas
Sep 12, 2022
As part of this issue, we essentially want to make sure that colocation_id do not get modified. To do this, we want to put checks on colocation_id wherever it can possibly get changed. There might be some other methods than the ones mentioned above which may change it.
|
Current state of things:
To summarize, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/ysql
Yugabyte SQL (YSQL)
kind/enhancement
This is an enhancement of an existing feature
priority/medium
Medium priority issue
Jira Link: [DB-376](https://yugabyte.atlassian.net/browse/DB-376)
pgtable_id
(nowcolocation_id
) for schemas are haphazardly set.CatalogManager::CreateTable
does not set itRaftGroupMetadata::AddTable
does set itCatalogManager::AlterTable
does set itCatalogManager::AddIndexInfoToTable
does not set itCatalogManager::MarkIndexInfoFromTableForDeletion
does not set itRaftGroupMetadata::SetSchema
does set it (since commit d92b234)Ideally,
pgtable_id
would be set from wherever it originates from: postgres create table and alter table requests to master. That way, we don't have to set it ad hoc on master and tserver. However, this may cause backwards compatibility issues.Another option is to set it from master:
CatalogManager::CreateTable
and ((CatalogManager::AddIndexInfoToTable
andCatalogManager::MarkIndexInfoFromTableForDeletion
) orAsyncAlterTable::SendRequest
). This enables us to get rid of the ad hoc setting at tserver.The text was updated successfully, but these errors were encountered: