Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitb1ee6da

Browse files
committed
Document why we copy reloptions into CacheMemoryContext after-the-fact.
1 parent50626ef commitb1ee6da

File tree

1 file changed

+7
-2
lines changed

1 file changed

+7
-2
lines changed

‎src/backend/utils/cache/relcache.c

Lines changed: 7 additions & 2 deletions
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)

[8]ページ先頭

©2009-2025 Movatter.jp