Re: PostgreSQL 8.0.6 crash - Mailing list pgsql-hackers

From Greg Stark
Subject Re: PostgreSQL 8.0.6 crash
Date
Msg-id 87lkwh6cdy.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: PostgreSQL 8.0.6 crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PostgreSQL 8.0.6 crash  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PostgreSQL 8.0.6 crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > That's why merely allocating tons of swap doesn't necessarily protect you.
> > It's still possible for a process (or several processes if you allocate more
> > swap than you have address space) to mmap gigabytes of memory without touching
> > it and then start touching those pages.
> 
> So?  If the swap exists to back that memory, there's no problem.  It
> might be slow, but it will not fail.

Sure, but there's no way to know how much swap you need. No matter how much
swap you allocate these processes can allocate more pages of untouched RAM and
then blow up.

Of course realistically allocating 4G of swap is enough to deal with something
like Postgres where you're not being maliciously attacked. One process on ia32
can't accidentally allocate more than 4G of ram.

I was just trying to clarify the situation since someone made some comment
about it having to do with memory being swapped out and then finding nowhere
to swap in when needed. That's not exactly what's happening.

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Upcoming re-releases
Next
From: Florian Weimer
Date:
Subject: Re: Upcoming re-releases