• Severity 2 - Major

      When CONF-21909 was prematurely merged to master, deployments containing that merge started down the road to OD deployment. The process was halted short of a full OD rollout, but got at least as far as DOG. The merge has since been reverted on master.

      This merge introduced new indexes to 5 different Confluence tables. These new indexes will now need to be manually unpicked from each database to which the deployment was applied.

            [AI-245] Remove bogus indexes created by CONF-21909

            I regret not having chased this up

            Olli Nevalainen added a comment - I regret not having chased this up

            Kenny MacLeod added a comment - - edited

            Audit of all possible affected databases:

            Environment Current build number Current dev version OK to drop indexes Dropped OK
            pug.jira-dev.com 5620 5.6-DEV-4642
            pug.jira.com 5620 5.6-DEV-4642
            eac-staging 5619 5.6-DEV-4629
            eac 5619 5.6-DEV-4629

            easenjo assures me that this is as far as this build would have got. DEV is currently not mapped to a real environment, and the build was not promoted to DOG.

            Kenny MacLeod added a comment - - edited Audit of all possible affected databases: Environment Current build number Current dev version OK to drop indexes Dropped OK pug.jira-dev.com 5620 5.6-DEV-4642 pug.jira.com 5620 5.6-DEV-4642 eac-staging 5619 5.6-DEV-4629 eac 5619 5.6-DEV-4629 easenjo assures me that this is as far as this build would have got. DEV is currently not mapped to a real environment, and the build was not promoted to DOG.

            Kenny MacLeod added a comment - - edited

            The bad merge (commit 90b5092) was first deployed to pug-dev as part of 5.6-DEV-4627, and then deployed to EAC as 5.6-DEV-4629.

            For each database that we believe may be affected, we need to locate the "bad" indexes that were created :

            select
                t.relname as table_name,
                i.relname as index_name,
                a.attname as column_name
            from
                pg_class t,
                pg_class i,
                pg_index ix,
                pg_attribute a
            where
                t.oid = ix.indrelid
                and i.oid = ix.indexrelid
                and a.attrelid = t.oid
                and a.attnum = ANY(ix.indkey)
                and t.relkind = 'r'
                and i.relname in ('fc_follower_idx','fc_followee_idx','sp_permusername_idx','spg_permusername_idx','cp_username_idx','pi_username_idx')
            order by
                t.relname,
                i.relname;
            

            The result set should be:

            table_name index_name column_name
            content pi_username_idx username
            content_perm cp_username_idx username
            follow_connections fc_followee_idx followee
            follow_connections fc_follower_idx follower
            spacegrouppermissions spg_permusername_idx permusername
            spacepermissions sp_permusername_idx permusername

            If this isn't an exact match, then we can't risk deleting anything without further investigation. See me after class.

            If this is an exact match, then we can proceed with the index drop:

            drop index fc_follower_idx;
            drop index fc_followee_idx;
            drop index sp_permusername_idx;
            drop index spg_permusername_idx;
            drop index cp_username_idx;
            drop index pi_username_idx;
            

            Kenny MacLeod added a comment - - edited The bad merge ( commit 90b5092 ) was first deployed to pug-dev as part of 5.6-DEV-4627 , and then deployed to EAC as 5.6-DEV-4629 . For each database that we believe may be affected, we need to locate the "bad" indexes that were created : select t.relname as table_name , i.relname as index_name, a .attname as column_name from pg_class t, pg_class i, pg_index ix, pg_attribute a where t.oid = ix.indrelid and i.oid = ix.indexrelid and a .attrelid = t.oid and a .attnum = ANY (ix.indkey) and t.relkind = 'r' and i.relname in ( 'fc_follower_idx' , 'fc_followee_idx' , 'sp_permusername_idx' , 'spg_permusername_idx' , 'cp_username_idx' , 'pi_username_idx' ) order by t.relname, i.relname; The result set should be: table_name index_name column_name content pi_username_idx username content_perm cp_username_idx username follow_connections fc_followee_idx followee follow_connections fc_follower_idx follower spacegrouppermissions spg_permusername_idx permusername spacepermissions sp_permusername_idx permusername If this isn't an exact match, then we can't risk deleting anything without further investigation. See me after class. If this is an exact match, then we can proceed with the index drop: drop index fc_follower_idx; drop index fc_followee_idx; drop index sp_permusername_idx; drop index spg_permusername_idx; drop index cp_username_idx; drop index pi_username_idx;

              onevalainen Olli Nevalainen
              kmacleod Kenny MacLeod
              Affected customers:
              0 This affects my team
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: