Re: [HACKERS] backend dies suddenly after a lot of error messages - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] backend dies suddenly after a lot of error messages
Date
Msg-id 25352.926531041@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] backend dies suddenly after a lot of error messages  (jwieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] backend dies suddenly after a lot of error messages
List pgsql-hackers
jwieck@debis.com (Jan Wieck) writes:
>> Yeah, I'd say so --- all the memory used should get freed at transaction
>> end, but evidently it isn't happening.

>     I  remember  to  have  taken  some  but haven't found all the
>     places.  I think there's still something in  tcop  where  the
>     querytree list is malloc()'d.

I saw that yesterday --- for no particularly good reason, postgres.c
wants to deal with the query list as an array rather than a list;
it goes to great lengths to convert the lists it's given into an array,
which it has to be able to resize, etc etc.  I was thinking of ripping
all that out and just using a palloc'd list.  At the time I didn't have
any justification for it except code beautification, which isn't a good
enough reason to be changing code late in beta... but a memory leak
is...

However, the leakage being complained of seems to be several kilobytes
per failed command, which is much more than that one malloc usage can
be blamed for.  Any other thoughts?  I was wondering if maybe a whole
palloc context somewhere is getting lost; not sure where to look though.
One thing I did find was that leakage occurs very early.  You can feed
the system commands that will fail in parsing, like saygarbage;
and the memory usage still rises with each one.
        regards, tom lane


pgsql-hackers by date:

Previous
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] Update Open Items list
Next
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: WHERE vs HAVING