From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Markus Wanner <markus(at)bluegap(dot)ch>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dynamically allocating chunks from shared memory |
Date: | 2010-08-09 20:18:26 |
Message-ID: | 13346.1281385106@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 9, 2010 at 3:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's not portable. That's exactly what we were looking into back when.
> Uggh, that sucks. Can you provide any more details?
You don't really have to go further than consulting the relevant
standards, eg SUS says at
http://www.opengroup.org/onlinepubs/007908799/xsh/mmap.html
If the size of the mapped file changes after the call to mmap() as a
result of some other operation on the mapped file, the effect of
references to portions of the mapped region that correspond to added
or removed portions of the file is unspecified.
Particular implementations might cope with such cases in useful ways, or
then again they might not. And even if your platform does, you've set
an upper limit for the possible segment size in your mmap() call.
Further down the page, SUS also takes pains to point out that you
probably can't have an unlimited number of mapped regions, so adding
more mmap'd segments isn't a way out either.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2010-08-09 20:26:43 | Re: patch: to_string, to_array functions |
Previous Message | Robert Haas | 2010-08-09 20:10:47 | Re: patch: to_string, to_array functions |