On Sun, Apr 17, 2011 at 11:48 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > =?utf-8?q?Rados=C5=82aw_Smogura?= <rsmog...@softperience.eu> writes: >> Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
