Re: using a lot of maintenance_work_mem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Frederik Ramm <frederik(at)remote(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: using a lot of maintenance_work_mem
Date: 2011-02-14 15:11:03
Message-ID: 19908.1297696263@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Frederik Ramm <frederik(at)remote(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-02-14 15:13:17 Re: why two dashes in extension load files
Previous Message Stephen Frost 2011-02-14 14:30:08 Re: Add support for logging the current role