Use a separate memory context for GIN scan keys.
It was getting tedious to track and release all the different things that
form a scan key. We were leaking at least the queryCategories array, and
possibly more, on a rescan. That was visible if a GIN index was used in a
nested loop join. This also protects from leaks in extractQuery method.
No backpatching, given the lack of complaints from the field. Maybe later,
after this has received more field testing.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/d88976cfa1302e8dccdcbfe55e9e29faee8c0cdf
Modified Files
--------------
src/backend/access/gin/ginget.c | 5 ++++-
src/backend/access/gin/ginscan.c | 43 ++++++++++++++++++++------------------
src/include/access/gin_private.h | 2 ++
3 files changed, 29 insertions(+), 21 deletions(-)
