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(-)
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера