From dfb30486d7a3d5bcb76de357d3980c61a58b9798 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 25 Jun 2005 16:54:00 +0000 Subject: [PATCH] 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. --- src/backend/catalog/index.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c index c0cd511daa1..f7d5bb9259d 100644 --- 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.244 2005/01/10 20:02:19 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.244.4.1 2005/06/25 16:54:00 tgl Exp $ * * * INTERFACE ROUTINES @@ -700,13 +700,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 -- 2.39.5