Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit b1ee6da

Browse files
committed
Document why we copy reloptions into CacheMemoryContext after-the-fact.
1 parent 50626ef commit b1ee6da

File tree

1 file changed

+7
-2
lines changed

1 file changed

+7
-2
lines changed

src/backend/utils/cache/relcache.c

+7-2
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/utils/cache/relcache.c,v 1.296 2010/01/05 01:06:56 tgl Exp $
11+
* $PostgreSQL: pgsql/src/backend/utils/cache/relcache.c,v 1.297 2010/01/07 20:39:45 rhaas Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -404,7 +404,12 @@ RelationParseRelOptions(Relation relation, HeapTuple tuple)
404404
relation->rd_rel->relkind == RELKIND_INDEX ?
405405
relation->rd_am->amoptions : InvalidOid);
406406

407-
/* Copy parsed data into CacheMemoryContext */
407+
/*
408+
* Copy parsed data into CacheMemoryContext. To guard against the
409+
* possibility of leaks in the reloptions code, we want to do the actual
410+
* parsing in the caller's memory context and copy the results into
411+
* CacheMemoryContext after the fact.
412+
*/
408413
if (options)
409414
{
410415
relation->rd_options = MemoryContextAlloc(CacheMemoryContext,

0 commit comments

Comments
 (0)