[YSQL][backup] Backup-restoring issue with OID double using for colocated tables.

[OlegLoginov]

Problem: backup-restore procedure calls 'ysqlsh' tool to apply YSQL dump (generated by 'ysql_dump' tool). The dump includes permanent OID for tables, but there is a chance that the OID has been already used by an internal PG object. As result the table (with the conflicting OID) cannot be created, and we can get the error:
"ERROR: Oid 16431 is in use."
Later 'yb-admin import_snapshot' step cannot find the table and the backup-restoring failed.

To reproduce the issue - run on a new cluster the dump:
./bin/ysqlsh -f YSQLDump1.txt

[OlegLoginov]

Uploading YSQLDump1.txt…

[OlegLoginov]

Related internal doc: https://docs.google.com/document/d/1M_y8OMSJJ9k4mp5vzeOqhmP6qYI21wzLKliB5Jd_RJc
Solution 2 (new mapping: table-oid -> colocated-oid) is preferable for now. (In SchemaPB protobuf. See the doc for details!!!)

[hulien22]

Not sure if this work-around is known, so thought I'd share this here:
One potential work-around while this issue is still being fixed is to artificially increase the next oids to be generated (since postgres shares the same oid generator for all dbs). For example, I created and dropped a bunch of tables on a new fresh cluster, and afterwards the ysqldump (from Oleg's example above) import was able to succeed:

# On a fresh cluster, run:
yugabyte=# do $$
begin
   for counter in 0..2000 loop
    EXECUTE format('CREATE TABLE IF NOT EXISTS test_%s (i int primary key, v int)', counter);
    EXECUTE format('DROP TABLE test_%s', counter);
   end loop;
end; $$;
DO
# This creates and drops 2000 tables (a bit overkill perhaps)

# Verify that we are past the highest table oid required in the ysqldump (around 22000)
yugabyte=# create table test (i int primary key);
CREATE TABLE
yugabyte=# select relname, oid from pg_class where oid >= 16384 and relkind='r';
 relname |  oid
---------+-------
 test    | 26389
(1 row)

# 26389 > 22000, so we're good
yugabyte=# drop table test;
yugabyte=# \q

# Now import the ysql_dump, which will succeed
~/code/yugabyte-db >>> ./bin/ysqlsh -f ~/Downloads/YSQLDump1.txt

Since all the objects that will be created will now have oid > 26389, we won't encounter any oid conflicts when creating the colocated tables with the set oids.

cc @oleg @m-iancu

[skorobogatydmitry]

Another case and workaround: https://docs.google.com/document/d/1enrW9MLPtVLhSRo0czcAnmy3ts7fTK93pyjHlD1ox6k/edit#heading=h.cej5c53no5ro

Workaround worked.