Re: memory leak in e94568ecc10 (pre-reading in external sort)

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to


Browse pgsql-hackers by date

  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