> 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...
I also thought the array usage we very strange,�and I could not figure
out why they used it. I figured as I learned more about the backend, I
would understnd their wisdom, but at this point, I think it was just
sloppy code.
> 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 say
> garbage;
> and the memory usage still rises with each one.
Gee, it garbage doesn't get very far into the parser, does it. It never
makes it out of the grammar. It may be the 8k query buffer?
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
