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

From Bruce Momjian
Subject [PATCHES] A patch for xlog.c
Date
Msg-id 200102260200.VAA17397@candle.pha.pa.us
Whole thread Raw
Responses Re: [PATCHES] A patch for xlog.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
[ Send to hackers]

> I'd be willing to consider using mmap as a compile-time option if it
> can be shown to be a substantial performance win where it's available.
> (I suspect that's a very big "if".)  If it's not a substantial win,
> I don't think we should accept the change --- the portability risks and
> testing/maintenance costs loom too large for me.
> 

I was considering it because you can use a much larger amount of shared
memory without reconfiguring the kernel.

> BTW, how exactly is mmap a substitute for SysV shared memory?  AFAICT
> it's only defined to map a disk file into your address space, not to
> allow a shared memory region to be set up that's independent of any
> disk file.

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
creatingMAP_ANON must be -1.                The offset parameter is ignored.
 
    MAP_FIXED   Do not permit the system to select a different address than                the one specified.  If the
specifiedaddress cannot be used,                mmap will fail.  If MAP_FIXED is specified, addr must be a
 multiple of the pagesize.  Use of this option is discouraged.
 
    MAP_PRIVATE                Modifications are private.
    MAP_SHARED  Modifications are shared.

We would use MAP_ANON|MAP_SHARED I guess.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Lincoln Yeoh
Date:
Subject: Re: RE: Re: [ADMIN] v7.1b4 bad performance
Next
From: Vince Vielhaber
Date:
Subject: Re: Monitor status