Re: First set of OSDL Shared Mem scalability results, some - Mailing list pgsql-performance

From Alan Stange
Subject Re: First set of OSDL Shared Mem scalability results, some
Date
Msg-id 416FC83F.3020900@rentec.com
Whole thread Raw
In response to Re: First set of OSDL Shared Mem scalability results, some wierdness ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Tom Lane wrote:

>Kevin Brown <kevin@sysexperts.com> writes:
>
>
>>Hmm...something just occurred to me about this.
>>
>>
>>Would a hybrid approach be possible?  That is, use mmap() to handle
>>reads, and use write() to handle writes?
>>
>>
>
>Nope.  Have you read the specs regarding mmap-vs-stdio synchronization?
>Basically it says that there are no guarantees whatsoever if you try
>this.  The SUS text is a bit weaselly ("the application must ensure
>correct synchronization") but the HPUX mmap man page, among others,
>lays it on the line:
>
>     It is also unspecified whether write references to a memory region
>     mapped with MAP_SHARED are visible to processes reading the file and
>     whether writes to a file are visible to processes that have mapped the
>     modified portion of that file, except for the effect of msync().
>
>It might work on particular OSes but I think depending on such behavior
>would be folly...
>
We have some anecdotal experience along these lines:    There was a set
of kernel bugs in Solaris 2.6 or 7 related to this as well.   We had
several kernel panics and it took a bit to chase down, but the basic
feedback was "oops.  we're screwed".   I've forgotten most of the
details right now; the basic problem was a file was being read+written
via mmap and read()/write() at (essentially) the same time from the same
pid.   It would panic the system quite reliably.  I believe the bugs
related to this have been resolved in Solaris, but it was unpleasant to
chase that problem down...

-- Alan

pgsql-performance by date:

Previous
From: "Leeuw van der, Tim"
Date:
Subject: Re: Select with qualified join condition / Batch inserts
Next
From: "Michael Nonemacher"
Date:
Subject: Re: Select with qualified join condition / Batch inserts