[DB Clone][YSQL] Clone to a time before drop table is failing in case of colocated databases

[yamen-haddad]

Jira Link: DB-12167

Description

Take the following experiment on a colocated database:

1. Create a table and load some data.
2. Mark time t.
3. Drop table.
4. Clone the database as of time t.
5. Check the table exists in the clone with the correct data.

Clone will fail at step 4 with the error:
ERROR: Clone operation aborted: Internal error (yb/master/catalog_manager_ext.cc:2336): Created table not found: 00004002000030008000000000004003.colocation.parent.uuid: OBJECT_NOT_FOUND (master error 3)

The problem is in ysql_dump step where the table group oid in the dump script is supposed to be identical to the tablegroup id at the source database. However the table group is set to 0 as the following snippet shows:

-- For YB colocation backup, must preserve implicit tablegroup pg_yb_tablegroup oid
SELECT pg_catalog.binary_upgrade_set_next_tablegroup_oid('0'::pg_catalog.oid);
CREATE TABLE public.t (
    k integer,
    v integer
)

Issue Type

kind/bug

Warning: Please confirm that this issue does not contain any sensitive information

• I confirm this issue does not contain any sensitive information.

[yamen-haddad]

More details on why is ysql_dump unable to set the tablegroup id correctly in the dump:
This is mainly because the tablegroup id is not set in the result of calling yb_table_properties() function on the dropped table. Ex:

db1=# set yb_read_time to 1721204283524280;
NOTICE:  yb_read_time should be set with caution.
DETAIL:  No DDL operations should be performed while it is set and it should not be set to a timestamp before a DDL operation has been performed. It doesn't have well defined semantics for normal transactions and is only to be used after consultation
SET
db1=# select * from yb_table_properties(16384);
 num_tablets | num_hash_key_columns | is_colocated | tablegroup_oid | colocation_id 
-------------+----------------------+--------------+----------------+---------------
           1 |                    0 | t            |                |    1878642346
(1 row)

db1=# 
 

The problem comes from the fact that the tablegroup manager will not have an entry of the dropped table inside its maps and thus the tablegroup manager will return a nullptr when asked to get the tablegroup of the dropped table using FindByTable.
This is mainly because we do not keep the table inside the in-memory maps (table_tablegroup_ids_map_, tablegroup_map_) of the tablegroup manager once the table is deleted. Check TgInfo::RemoveChildTable for more details.

[yamen-haddad]

The solution can be one of the two ways:
1- Not delete the dropped table from the in-memory map and instead mark it as hidden when the table is covered by a snapshot schedule.
2- Search for the tablegroup id using the parent colocated table id. This solution is easier and less disruptive. This works as we only want the tablegroup id for clone and we are not interested in other fields of the TableGroupInfo object.

I am leaning toward solution 2 as it is more straight forward and dealing with hiding tablegroup mappings means persisting this info in sys catalog. This seems an overkill for the purpose of getting the tablegroup id which we can get from the parent table.