| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Wu Ivy <ivywuyzl(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: SPI_cursor_fetch Memory overrun |
| Date: | 2018-08-23 00:08:47 |
| Message-ID: | 8729.1534982927@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Wu Ivy <ivywuyzl(at)gmail(dot)com> writes:
> fprintf(fp, (i == tupdesc->natts) ? "%s\n" : "%s," , SPI_getvalue(tuple, tupdesc, i));
That (specifically the SPI_getvalue call) is what's leaking memory.
You could improve matters by pfree'ing the result string after each
such call.
Just to add insult to injury, it's also looking up the column datatype's
output function afresh on every call. There could perhaps be some leakage
involved in those lookups too, though I'd bet the main problem is the
result strings.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-08-23 00:09:05 | Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c) |
| Previous Message | Andres Freund | 2018-08-22 23:13:01 | Re: Query is over 2x slower with jit=on |