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 cdc3ccb3-496f-7ad8-f4cd-e07215f83809@iki.fi
Whole thread Raw
In response to Re: memory leak in e94568ecc10 (pre-reading in external sort)  (Peter Geoghegan <pg@heroku.com>)
List 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




pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: int2vector and btree indexes
Next
From: Michael Paquier
Date:
Subject: Re: Quorum commit for multiple synchronous replication.