Hi,
On 2013-06-27 19:05:22 +0000, Noah Misch wrote:
> Permit super-MaxAllocSize allocations with MemoryContextAllocHuge().
>
> The MaxAllocSize guard is convenient for most callers, because it
> reduces the need for careful attention to overflow, data type selection,
> and the SET_VARSIZE() limit. A handful of callers are happy to navigate
> those hazards in exchange for the ability to allocate a larger chunk.
> Introduce MemoryContextAllocHuge() and repalloc_huge(). Use this in
> tuplesort.c and tuplestore.c, enabling internal sorts of up to INT_MAX
> tuples, a factor-of-48 increase. In particular, B-tree index builds can
> now benefit from much-larger maintenance_work_mem settings.
This commit causes a bunch of warnings like:
src/backend/utils/sort/tuplesort.c: In function ‘tuplesort_begin_common’:
src/backend/utils/sort/tuplesort.c:399:33: warning: comparison of unsigned expression < 0 is always false
[-Wtype-limits]
#define LACKMEM(state) ((state)->availMem < 0)
to be thrown during compilation. And I think it is spot on. Unless you
overhaul a good bit of the respective logic making availMem unsigned
isn't going to fly.
As is, that code will probably be optimized away which isn't good...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services