Re: Pre-allocation of shared memory ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Pre-allocation of shared memory ...
Date
Msg-id 9768.1055431191@sss.pgh.pa.us
Whole thread Raw
In response to Re: Pre-allocation of shared memory ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Pre-allocation of shared memory ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Pre-allocation of shared memory ...  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What really kills [:-)] me is that they allocate memory assuming I will
> not be using it all, then terminate the executable in an unrecoverable
> way when I go to use the memory.

To be fair, I'm probably misstating things by referring to malloc().
The big problem probably comes from fork() with copy-on-write --- the
kernel has no good way to estimate how much of the shared address space
will eventually become private modified copies, but it can be forgiven
for wanting to make less than the worst-case assumption.

Still, if you are wanting to run a reliable server, I think worst-case
assumption is exactly what you want.  Swap space is cheap, and there's
no reason you shouldn't have enough swap to support the worst-case
situation.  If the swap area goes largely unused, that's fine.

The policy they're calling "paranoid overcommit" (don't allocate more
virtual memory than you have swap) is as far as I know the standard on
all Unixen other than Linux; certainly it's the traditional behavior.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Pre-allocation of shared memory ...
Next
From: Bruce Momjian
Date:
Subject: Re: Pre-allocation of shared memory ...