Re: Providing anonymous mmap as an option of sharing memory - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Providing anonymous mmap as an option of sharing memory
Date
Msg-id 200311261839.hAQIdUU10597@candle.pha.pa.us
Whole thread Raw
In response to Re: Providing anonymous mmap as an option of sharing memory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes:
> > I covered only first point in my post. IMO it is not such a unsolvable
> > problem.  If a postmaster crashes hard but leaves a backend running,
> > would it clean pid file etc? I don't think so. So if a postmaster can
> > start on a 'pid-clean' state, then it is guaranteed to be no childs
> > left around.
> 
> And that helps how?  The problem is to detect whether there are any
> children left from the old postmaster, when what you have to work from
> is the pid-file it left behind.
> 
> In any case, you're still handwaving away the very real portability
> issues around mmap.  Linux is not the universe, and Linux+BSD isn't
> either.
> 
> We might still have considered it, despite the negatives, if anyone had
> been able to point to any actual *advantages* of mmap.  There are none.
> Yes, the SysV shmem API is old and ugly and crufty, but it does what we
> need it to do.

Plus many operating systems can lock SvssV shmem into RAM to prevent it
from being swapped out.

--  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: Tom Lane
Date:
Subject: Re: pg_restore and create FK without verification check
Next
From: Andreas Pflug
Date:
Subject: Re: pg_restore and create FK without verification check