[YSQL] The condition of "switching to per-db mode" should be refined

[myang2021]

Jira Link: DB-7979

Description

In recent debugging of GHI issue #18711 I found an issue inside function YBIsDBCatalogVersionMode(). During connection establishment time, the following events happen in order:

1. RelationCacheInitialize()
2. YbGetCatalogCacheVersionForTablePrefetching()

        /*
         * If per database catalog version mode is enabled, this will load the
         * catalog version of template1. It is fine because at this time we
         * only read shared relations and therefore can use any database OID.
         * We will update yb_catalog_cache_version to match MyDatabaseId once
         * the latter is resolved so we will never use the catalog version of
         * template1 to query relations that are private to MyDatabaseId.
         */
        YbUpdateCatalogCacheVersion(YbGetMasterCatalogVersion());

4. RelationCacheInitializePhase2()
5. MyDatabaseId is resolved

    if (MyDatabaseId != TemplateDbOid && YBIsDBCatalogVersionMode())
    {
        /*
         * Here we assume that the entire table pg_yb_catalog_version is
         * prefetched. Note that in this case YbGetMasterCatalogVersion()
         * returns the prefetched catalog version of MyDatabaseId which is
         * consistent with all the other tables that are prefetched.
         */
        uint64_t master_catalog_version = YbGetMasterCatalogVersion();
        Assert(master_catalog_version > YB_CATCACHE_VERSION_UNINITIALIZED);
        YbUpdateCatalogCacheVersion(master_catalog_version);
    }

The first call to YBIsDBCatalogVersionMode() is during connection setup is made in step 2 by YbGetCatalogCacheVersionForTablePrefetching(). If the cluster is already running in per-database catalog version mode, each connection still goes through the following code

        yb_last_known_catalog_cache_version = 1;
        YbUpdateCatalogCacheVersion(1);
        elog(DEBUG3, "switching to per-db mode");

This isn't needed if YBIsDBCatalogVersionMode() is called before step 6, because the version 1 set here will be overwritten by the call to YbUpdateCatalogCacheVersion in step 6. This is similar to a useless assignment that can be optimized away. Secondly, for template1, we should not reset catalog version to 1 because the upgrade script does not change the catalog version of template1. We do have internally generated connections to template1 and a user can also make an explicit connection to template1. In a connection to template1, if we reset template1's catalog version to 1, it can cause unnecessary catalog cache refresh.

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

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