[docdb][colocation] Dropped colocated table still referenced in TabletInfo #11129
Labels
area/docdb
YugabyteDB core features
area/ysql
Yugabyte SQL (YSQL)
kind/bug
This issue is a bug
kind/disk-format-change
This feature will change the on-disk format.
priority/medium
Medium priority issue
Jira Link: DB-1190
Description
When doing DROP TABLE on a colocated user table, the
TabletInfo
PB'stable_ids
repeated field still contains the table id of the dropped user table. It doesn't look like there's any attempt to remove it, unlike on DROP DATABASE whereDeleteYsqlDBTables
callsRemoveTableIdsFromTabletInfo
.@frozenspider encountered the failure related to this. I produced a repro:
First, apply (on commit 040673f):
Then, create a fresh cluster, create and connect to a colocated database, create two tables, drop the first table, and run
yb-admin -master_addresses=... get_colocated_tablet_schema $(yb-admin -master_addresses=... list_tables include_table_id | grep colocated | awk '{print$2}')
.yb-admin
should return the second user table:Master logs should show two user tables and the parent table, like
00004000000030008000000000004001
was the first table and should have been removed from the colocated tablet's TabletInfo on master. Since this is persisted, a restart of master will still have it. The tablet on tserver seems to be fine at doing the ChangeMetadataMetadataChange::REMOVE_TABLE
and updating its kvstore.Creating a new table with the same id (using
WITH (table_oid = ...)
doesn't seem to have issues with some basic testing. However, if any code from master reads the table_ids of the colocated tablet TabletInfo, it should not assume that those tables are colocated!keywords: colocated tablet, colocated user table, table_ids repeated protobuf field, metadata, PersistentTabletInfo, tablegroup
The text was updated successfully, but these errors were encountered: