Frederik Ramm <frede...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers