Frederik Ramm <frederik@remote.org> writes:
> Now I assume that there are reasons that you're doing this. memutils.h
> has the (for me) cryptic comment about MaxAllocSize: "XXX This is
> deliberately chosen to correspond to the limiting size of varlena
> objects under TOAST. See VARATT_MASK_SIZE in postgres.h.", but
> VARATT_MASK_SIZE has zero other occurences in the source code.
Hm, I guess that comment needs updated then.
> If I were to either (a) increase MaxAllocSize to, say, 48 GB instead of
> 1 GB, or (b) hack tuplesort.c to ignore MaxAllocSize, just for my local
> setup - would that likely be viable in my situation, or would I break
> countless things?
You would break countless things. It might be okay anyway in a trusted
environment, ie, one without users trying to crash the system, but there
are a lot of security-critical implications of that test.
If we were actually trying to support such large allocations,
what I'd be inclined to do is introduce a separate call along the lines
of MemoryContextAllocLarge() that lacks the safety check. But before
expending time on that, I'd want to see some evidence that it's actually
helpful for production situations. I'm a bit dubious that you're going
to gain much here.
regards, tom lane