Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] A patch for xlog.c

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PATCHES] A patch for xlog.c
Date: 2001-02-26 04:48:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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 shared only 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.

Agreed.  It would make it impossible and a possible limitation.

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

I figured mmap() was different than SysV becuase mmap() is file based.

I have had this item on the TODO list for a while:

	* Use mmap() rather than SYSV shared memory(?)

Should I remove it?

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2001-02-26 04:58:45
Subject: Re: [PATCHES] A patch for xlog.c
Previous:From: Lincoln YeohDate: 2001-02-26 04:39:39
Subject: Re: offset and limit in update and subselect

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group