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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: memory leak in e94568ecc10 (pre-reading in external sort)
Дата
Msg-id 9f997ab1-5f3a-cf79-b92b-dc170ec75043@iki.fi
обсуждение исходный текст
Ответ на memory leak in e94568ecc10 (pre-reading in external sort)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: memory leak in e94568ecc10 (pre-reading in external sort)  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Relids in upper relations
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Declarative partitioning - another take