Re: [PATCHES] A patch for xlog.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] A patch for xlog.c
Date
Msg-id 22318.983161726@sss.pgh.pa.us
Whole thread Raw
In response to [PATCHES] A patch for xlog.c  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [PATCHES] A patch for xlog.c  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Re: [PATCHES] A patch for xlog.c  (ncm@zembu.com (Nathan Myers))
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> It allows no backing store on disk.  It is the BSD solution to SysV
> share memory.  Here are all the BSDi flags:

>      MAP_ANON    Map anonymous memory not associated with any specific file.
>                  The file descriptor used for creating MAP_ANON must be -1.
>                  The offset parameter is ignored.

Hmm.  Now that I read down to the "nonstandard extensions" part of the
HPUX man page for mmap(), I find
    If MAP_ANONYMOUS is set in flags:
         o    A new memory region is created and initialized to all zeros.              This memory region can be
sharedonly with descendants of              the current process.
 

While I've said before that I don't think it's really necessary for
processes that aren't children of the postmaster to access the shared
memory, I'm not sure that I want to go over to a mechanism that makes it
*impossible* for that to be done.  Especially not if the only motivation
is to avoid having to configure the kernel's shared memory settings.

Besides, what makes you think there's not a limit on the size of shmem
allocatable via mmap()?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Lincoln Yeoh
Date:
Subject: Re: offset and limit in update and subselect
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] A patch for xlog.c