On Fri, Mar 11, 2016 at 11:40 PM, Jaime Casanova
<jaime.casan...@2ndquadrant.com> wrote:
> Hi,
> On the spanish list, Felipe de Jesús Molina Bravo, reported a few days
> back that a query that worked well in 9.4 consume all memory in 9.5.
> With the self contained test he provided us i reproduced the problem
> in 9.5 and 9.6dev.
> To test, execute:
> pba.sql -- to create the tables and populate
> query_crash.sql -- this will consume all your memory and crash your
> server eventually
> If you drop the GIN indexes, the problem disappear.
> I used valgrind to try to hunt the memory leak, attached the resulting
> log showing the backend that executed the query. And from the little a
> could say from the stack trace valgrind showed, the problem is around
> ginPostingListDecodeAllSegments() but i don't see any modifications
> there.

I bisected it down to:

d88976cfa1302e8dccdcbfe55e9e29faee8c0cdf is the first bad commit
commit d88976cfa1302e8dccdcbfe55e9e29faee8c0cdf
Author: Heikki Linnakangas <heikki.linnakan...@iki.fi>
Date:   Wed Feb 4 17:40:25 2015 +0200

    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.

I won't have a chance to do any further analysis for a while.



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to