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
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 |