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

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: memory leak in e94568ecc10 (pre-reading in external sort)
Date: 2016-10-11 08:45:15
Message-ID: cdc3ccb3-496f-7ad8-f4cd-e07215f83809@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/11/2016 12:56 AM, Peter Geoghegan wrote:
> Also, something about trace_sort here:
>
>> +#ifdef TRACE_SORT
>> + if (trace_sort)
>> + elog(LOG, "using " INT64_FORMAT " KB of memory for read buffers among %d input tapes",
>> + (state->availMem) / 1024, numInputTapes);
>> +#endif
>> +
>> + state->read_buffer_size = state->availMem / numInputTapes;
>> + USEMEM(state, state->availMem);
>
> Maybe you should just make the trace_sort output talk about blocks at
> this point?

With # of blocks, you then have to mentally divide by 8 to get the
actual memory used. I think kB is nicer in messages that are meant to be
read by humans.

The bigger problem with this message is that it's not very accurate
anymore. The actual amount of memory used is rounded down, and capped by
MaxAllocSize*numInputTapes. And would it be better to print the per-tape
buffer size, rather than the total?

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-10-11 09:08:12 Re: Quorum commit for multiple synchronous replication.
Previous Message Amit Langote 2016-10-11 08:37:31 Re: int2vector and btree indexes