aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2011-09-16 04:28:11 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2011-09-16 04:28:11 -0400
commit0bbbf592153c31ac5e095db2956e947c15c8435b (patch)
tree3002bc0b11b7e3b7b89e13bf414611b8f5162341
parent7f7ed1716dea32ebe1f504c16538a175a075c758 (diff)
downloadpostgresql-0bbbf592153c31ac5e095db2956e947c15c8435b.tar.gz
postgresql-0bbbf592153c31ac5e095db2956e947c15c8435b.zip
gistendscan() forgot to free so->giststate.
This oversight led to a massive memory leak --- upwards of 10KB per tuple --- during creation-time verification of an exclusion constraint based on a GIST index. In most other scenarios it'd just be a leak of 10KB that would be recovered at end of query, so not too significant; though perhaps the leak would be noticeable in a situation where a GIST index was being used in a nestloop inner indexscan. In any case, it's a real leak of long standing, so patch all supported branches. Per report from Harald Fuchs.
-rw-r--r--src/backend/access/gist/gistscan.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/src/backend/access/gist/gistscan.c b/src/backend/access/gist/gistscan.c
index 39e7d32bf29..d954581e3aa 100644
--- a/src/backend/access/gist/gistscan.c
+++ b/src/backend/access/gist/gistscan.c
@@ -236,14 +236,17 @@ gistendscan(PG_FUNCTION_ARGS)
gistfreestack(so->stack);
gistfreestack(so->markstk);
if (so->giststate != NULL)
+ {
freeGISTstate(so->giststate);
+ pfree(so->giststate);
+ }
/* drop pins on buffers -- we aren't holding any locks */
if (BufferIsValid(so->curbuf))
ReleaseBuffer(so->curbuf);
if (BufferIsValid(so->markbuf))
ReleaseBuffer(so->markbuf);
MemoryContextDelete(so->tempCxt);
- pfree(scan->opaque);
+ pfree(so);
}
PG_RETURN_VOID();