During the initdb process, it may generate possibly-non-unique OID for system table entries. (Table and relation are used to mean the same thing in the following discussion.) The first location where this happens is the “Setup auth …” step, where it needs to generate a new entry in the pg_auth_history system table when it processes the “ALTER USER omm WITH PASSWORD E'Test3456';” statement.
The message we get is like: [BACKEND] WARNING: generating possibly-non-unique Oid for "pg_auth_history".
Findings
Each system table/relation, such as pg_auth_history, may have multiple indexes. The oid index is one of them. For example, pg_auth_history table has the oid index (which is a unique index on the oid column), and another index on two columns, roloid and passwordtime.
Indexes of many system tables (if not all) are stored in the pg_index system table. The indexList and the oidIndex of a system table can be obtained by doing a scan on the pg_index system table. When a new row needs to be created with an oid in a system table, it needs to generate a new oid for the row, by calling the GetNewOid() method.
The GetNewOid() method will first check if the relation has a valid oid index. If so, the GetNewOid() method will generate a unique oid based on the oid index. Otherwise, the GetNewOid() method will generate the warning, and call the GetNewObjectId() to generate a possbily-non-unique oid.
Debugging within the GetNewOid() method reveals that the oid index for a system table exists in the pg_index table in k2 cluster, and can be read back correctly into the heaptuple. (The oid of the oid index is the indexrelid field of the pg_index system table, while the indrelid field of the pg_index table refers to the corresponding table/relation.) However, there isn’t a flag in an index to tell us whether it is the oid index or not.
Cause of the issue
In the RelationGetIndexList() function in relcache.cpp, there is a complex logic to determine whether an index is the oid index. It only updates the oidIndex after it identifies the oid index. In vanilla opengauss, the if condition will evaluate to true when an index is the oid index. However, in k2 opengauss, the if condition will evaluate to false even when an index is the oid index. Thus, the oidIndex of a relation is always the InvalidOid (0) in k2 opengauss. This will trigger the GetNewOid() method to generate the warning for many system tables.
Potential directions to resolve the issue
Check whether the added field, “t_k2pgctid” in HeapTupleData affects the logic of determining whether an index for a system table/relation is the oid index.
There are some minor differences in other fields (e.g., t_self) of HeapTupleData, between k2 opengauss and vanilla opengauss. Check whether these differences affect the logic of determining whether an index is the oid index. (These differences may be expected since we are using k2 as the storage for opengauss. Need investigation.)
Symptom
During the initdb process, it may generate possibly-non-unique OID for system table entries. (Table and relation are used to mean the same thing in the following discussion.) The first location where this happens is the “Setup auth …” step, where it needs to generate a new entry in the pg_auth_history system table when it processes the “ALTER USER omm WITH PASSWORD E'Test3456';” statement.
The message we get is like: [BACKEND] WARNING: generating possibly-non-unique Oid for "pg_auth_history".
Findings
Cause of the issue
In the RelationGetIndexList() function in relcache.cpp, there is a complex logic to determine whether an index is the oid index. It only updates the oidIndex after it identifies the oid index. In vanilla opengauss, the if condition will evaluate to true when an index is the oid index. However, in k2 opengauss, the if condition will evaluate to false even when an index is the oid index. Thus, the oidIndex of a relation is always the InvalidOid (0) in k2 opengauss. This will trigger the GetNewOid() method to generate the warning for many system tables.
Potential directions to resolve the issue