Tom,
Here is what we found.
The error is from tuplestore.c in the grow_memtuples() function. It
probably applies to tuplesort.c as well.
WARNING: orig_memtupsize: 1024
WARNING: orig_memtuples_size: 4104
WARNING: orig_availMem: 2544
WARNING: newmemtupsize: 1025
WARNING: new_memtuples_size: 8200
WARNING: new_availMem: -1552
WARNING: code_path: 1
code_path indicates that the growth_ratio algorithm path was taken.
It looks like the culprit is chunk size algorithm. The
orig_memtuples_size is 4096 bytes (plus 8 byte header). It is fully used
(1024(orig_memtuples_size) x 4(size of void *)). The growth_ratio
algorithm determines that is can fit 1 more tuple setting newmemtupesize
to 1025. The repalloc requests 4100 bytes but the chunk size algorithm
uses chunks of size N^2. So the next chunk is 8192 bytes plus 8 byte
header. This blows past orig_availMem of 2544 and causes LACKMEM to be
TRUE.
I see a few options.
- Don't check LACKMEM here. It hardly get checked anywhere else.
- Don't use growth_ratio if the new repalloc request will be <= 8kB.
- When new repalloc is <= 8kB over allocate allowedMem, increase
newmemtupsize to fully use new chunk size.
Let me know what your plans are.
Brent DeSpain
Automation & Integration Engineering
Schweitzer Engineering Laboratories, Inc.
Boise, ID
Wk: 509-334-8007
mailto:brent_despain@selinc.com
From: Tom Lane <tgl@sss.pgh.pa.us>
To: brent_despain@selinc.com,
Cc: pgsql-bugs@postgresql.org
Date: 08/01/2015 11:56 AM
Subject: Re: [BUGS] BUG #13530: sort receives "unexpected
out-of-memory situation during sort"
I wrote:
> brent_despain@selinc.com writes:
>> We are occasionally receiving "unexpected out-of-memory situation
during
>> sort".
> Hmm. Looking at the code here, it suddenly strikes me that it's
assuming
> that LACKMEM() wasn't true to begin with, and that this is not
guaranteed,
> because we adjust the memory consumption counter *before* we call
> puttuple_common.
In the light of day that theory doesn't hold up, because if LACKMEM
were true on entry (ie, availMem < 0) then we'd compute a grow_ratio
less than one, so that the "Must enlarge array by at least one element"
check would trigger, and we'd never get to the code that's failing.
Another idea that occurred to me is that the "memory chunk overhead won't
increase" assumption could fail if sizeof(SortTuple) weren't a multiple of
MAXALIGN (because repalloc internally rounds the request up to a MAXALIGN
boundary) but that doesn't seem plausible either. I'd expect that struct
to be 16 bytes on 32-bit or 24 bytes on 64-bit, so it should be maxaligned
on any hardware I know about.
So I'm about out of ideas. Could you modify your copy of the code to
log interesting details when you get this error, like the old and new
memtupsize and chunk space measurements? That might give us a clue
what's the problem.
regards, tom lane
