On Sun, Apr 17, 2011 at 11:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Radosław Smogura <rsmogura@softperience.eu> writes:
>> Tom Lane <tgl@sss.pgh.pa.us> Sunday 17 April 2011 01:35:45
>>> ... Huh? Are you saying that you ask the kernel to map each individual
>>> shared buffer separately? I can't believe that's going to scale to
>>> realistic applications.
>
>> No, I do
>> mrempa(mmap_buff_A, MAP_FIXED, temp);
>> mremap(shared_buff_Y, MAP_FIXED, mmap_buff_A),
>> mrempa(tmp, MAP_FIXED, mmap_buff_A).
>
> There's no mremap() in the Single Unix Spec, nor on my ancient HPUX box,
> nor on my quite-up-to-date OS X box. The Linux man page for it says
> "This call is Linux-specific, and should not be used in programs
> intended to be portable." So if the patch is dependent on that call,
> it's dead on arrival from a portability standpoint.
>
> But in any case, you didn't explain how use of mremap() avoids the
> problem of the kernel having to maintain a separate page-mapping-table
> entry for each individual buffer. (Per process, yet.) If that's what's
> happening, it's going to be a significant performance penalty as well as
> (I suspect) a serious constraint on how many buffers can be managed.
I share your suspicions, although no harm in measuring it.
But I don't understand is how this approach avoids the problem of
different processes seeing different buffer contents. If backend A
has the buffer mmap'd and backend B wants to modify it (and changes
the mapping), backend A is still looking at the old buffer contents,
isn't it? And then things go boom.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
