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-9zs...@mail.gmail.com would also have been avoided, if we had done that. So I think we should reconsider that.

- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to