Re: memory leak in e94568ecc10 (pre-reading in external sort) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: memory leak in e94568ecc10 (pre-reading in external sort)
Date
Msg-id 9f997ab1-5f3a-cf79-b92b-dc170ec75043@iki.fi
Whole thread Raw
In response to memory leak in e94568ecc10 (pre-reading in external sort)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: memory leak in e94568ecc10 (pre-reading in external sort)  (Peter Geoghegan <pg@heroku.com>)
List 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@mail.gmail.com would 
also have been avoided, if we had done that. So I think we should 
reconsider that.

- Heikki




pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Relids in upper relations
Next
From: Amit Langote
Date:
Subject: Re: Declarative partitioning - another take