| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)heroku(dot)com> |
| Subject: | Re: memory leak in e94568ecc10 (pre-reading in external sort) |
| Date: | 2016-10-06 07:00:06 |
| Message-ID: | 9f997ab1-5f3a-cf79-b92b-dc170ec75043@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/06/2016 07:50 AM, Tomas Vondra wrote:
> it seems e94568ecc10 has a pretty bad memory leak. A simple
Oops, fixed, thanks for the report!
To be precise, this wasn't a memory leak, just a gross overallocation of
memory. The new code in tuplesort.c assumes that it's harmless to call
LogicalTapeRewind() on never-used tapes, but in fact, it allocated the
read buffer for the tape. I fixed that by changing LogicalTapeRewind()
to not allocate it, if the tape was completely empty.
This is related to earlier the discussion with Peter G, on whether we
should change state->maxTapes to reflect the actual number of tape that
were used, when that's less than maxTapes. I think his confusion about
the loop in init_tape_buffers(), in
CAM3SWZQ7=FCy1iUZ6jNzUUNnktAG6uitC1i-DoNxScP-9ZsHwQ(at)mail(dot)gmail(dot)com would
also have been avoided, if we had done that. So I think we should
reconsider that.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2016-10-06 07:14:04 | Re: Declarative partitioning - another take |
| Previous Message | Ashutosh Bapat | 2016-10-06 06:46:37 | Re: Relids in upper relations |