Fix ancient memory leak in index_create(): RelationInitIndexAccessInfo

was being called twice in normal operation, leading to a leak of one set
of relcache subsidiary info.  Per report from Jeff Gold.

diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index b7ad416c2b3c61e573158c4a3633b4b05fd7ef78..89ba99c44845a378eb0e437d14a5bdf91d8745c5 100644 (file)
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *   $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.257 2005/06/20 02:07:47 neilc Exp $
+ *   $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.258 2005/06/25 16:53:49 tgl Exp $
  *
  *
  * INTERFACE ROUTINES
@@ -704,13 +704,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