On Mon, 2 Jun 1997, Tymm Twillman wrote:
> On Mon, 2 Jun 1997, Igor wrote:
>
> > Well...I put these PQclear's in because there were memory leaks in that
> > area. If you put it outside, of the case statement, you start clearing
> > already freed tuples causing a mess (Marc.. that was the reason why
> > regression screwed up on boolean). Now, there are a few more memory leaks
> > (particularly with PGsettings *settings variable) but it doesn't leak much
> > and will be left alone until 6.2 probably.
> > I guess if you do if(results) PQclear (results)...oh well...There are no
> > memory leaks from PQexec anymore so might just as well leave it alone for
> > now.
>
> Sorry, I should have said outside of the switch statement. With the
> current code, if the result of the exec is an error, the returned value
> (results) from PQexec is not freed. It's a very small leak, but Purify
> was kicking it out. I removed all of the PQclears from the individual
> statements and moved them to the bottom of the switch.
>
> (I'm sorry if I'm just misunderstanding what you are saying...)
>
> BTW, I'd also like to apologize for the tone of my messages earlier (and
> the poorly constructed patches); it is a mixture of being new to the
> postgresql project and a major lack of sleep.
>
> -Tymm
>
>
OK, sorry, just dug through a bit more. OK; in the case of
PGRES_NONFATAL_ERROR, the results have already been freed. In that case,
I guess that the lines should be
case PGRES_FATAL_ERROR:
case PGRES_BAD_RESPONSE:
PQclear(results);
case PGRES_NONFATAL_ERROR:
*success_p = false;
fprintf(stderr, "%s", PQerrorMessage(settings->db));
break;
leaving the PQclears inside the switch.
My apologies for denseness.
- -Tymm
------------------------------
