> > >Running postgresql in interactive mode shows that for each query I
> > >type there is memory lost. The exact amount of memory lost depends on
> > >the query I use. The amount of memory not freed is also a function
> > >of the number of tuples returned.
> > >
> >
> > Oops, it seems some palloc'ed memory is not freed by pfree() but
> > using some other function(s).
> > My mistake, sorry.
>
> OK, I think I know where the leak is from. I checked AllocSetDump(), and
> it did not show any problems with any context growing, so I started to
> suspect direct calls to malloc(). I tried trapping on malloc(), but
> there are too many calls.
>
> Then I ran profiling on the two queries I mentioned, where one leaks and
> one doesn't, and found that the leaking one had 500 extra calls to
> malloc. Grep'ing out the calls and comparing the output of the two
> profiles, I found:
>
> 0.00 0.00 1/527 ___irs_gen_acc [162]
> 0.00 0.00 35/527 _GetDatabasePath [284]
> 0.00 0.00 491/527 _GetDatabaseName [170]
> [166] 0.8 0.00 0.00 527 _strdup [166]
> 0.00 0.00 527/2030 _malloc [105]
> 0.00 0.00 527/604 _strlen [508]
> 0.00 0.00 527/532 _bcopy [515]
>
>
> I believe this code was modified by Vadim to fix our problem with blind
> write errors when using psql while the regression tests were being run.
>
> Am I correct on this? I have not developed a fix yet.
How about changing the strdup()'s in src/backend/utils/init/miscinit.c to
the pstrdup() that is in palloc.c so the memory is palloc()/pfree()'d?
I seem to recall a discussion a long time ago about using strdup and how
it would leak when using the postgres memory contexts, and that the pstrdup
code was created to be used instead of strdup to "fix" this.
darrenk
