Fix ancient memory leak in index_create(): RelationInitIndexAccessInfo
authorTom Lane <[email protected]>
Sat, 25 Jun 2005 16:54:12 +0000 (16:54 +0000)
committerTom Lane <[email protected]>
Sat, 25 Jun 2005 16:54:12 +0000 (16:54 +0000)
was being called twice in normal operation, leading to a leak of one set
of relcache subsidiary info.  Per report from Jeff Gold.

src/backend/catalog/index.c

index 6d9a7c2cb4846330ab0254bdf4c068860a1e9b49..446e20c28fb14d353644fd3014b811e536fd04c9 100644 (file)
@@ -707,13 +707,21 @@ index_create(Oid heapRelationId,
        }
 
        /*
-        * Fill in the index strategy structure with information from the
-        * catalogs.  First we must advance the command counter so that we
-        * will see the newly-entered index catalog tuples.
+        * Advance the command counter so that we can see the newly-entered
+        * catalog tuples for the index.
         */
        CommandCounterIncrement();
 
-       RelationInitIndexAccessInfo(indexRelation);
+       /*
+        * In bootstrap mode, we have to fill in the index strategy structure
+        * with information from the catalogs.  If we aren't bootstrapping,
+        * then the relcache entry has already been rebuilt thanks to sinval
+        * update during CommandCounterIncrement.
+        */
+       if (IsBootstrapProcessingMode())
+               RelationInitIndexAccessInfo(indexRelation);
+       else
+               Assert(indexRelation->rd_indexcxt != NULL);
 
        /*
         * If this is bootstrap (initdb) time, then we don't actually fill in