Re: PostgreSQL 8.0.6 crash - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: PostgreSQL 8.0.6 crash
Date
Msg-id 200602111725.k1BHPTn29203@candle.pha.pa.us
Whole thread Raw
In response to Re: PostgreSQL 8.0.6 crash  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark wrote:
> 
> 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.

I guess the fundamental issue is whether Linux requires all mmap()'ed
file contents to be in memory, or whether it pushes data to disk and
unmaps it as it runs low on memory.  I don't know the answer to that.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Upcoming re-releases
Next
From: Tom Lane
Date:
Subject: Re: PostgreSQL 8.0.6 crash