From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aleksey Demakov <ademakov(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Experimental dynamic memory allocation of postgresql shared memory |
Date: | 2016-06-17 18:45:49 |
Message-ID: | 29414.1466189149@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aleksey Demakov <ademakov(at)gmail(dot)com> writes:
> On Fri, Jun 17, 2016 at 10:54 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Jun 17, 2016 at 12:34 PM, Aleksey Demakov <ademakov(at)gmail(dot)com> wrote:
>>> I believe it would be perfectly okay to allocate huge amount of address
>>> space with mmap on startup. If the pages are not touched, the OS VM
>>> subsystem will not commit them.
>> In my opinion, that's not going to fly. If I thought otherwise, I
>> would not have developed the DSM facility in the first place.
> Essentially this is pessimizing for the lowest common denominator
> among OSes.
You're right, but that doesn't mean that the community is going to take
much interest in an unportable replacement for code that already exists.
Especially not an unportable replacement that also needs sweeping
assumptions like "disciplined use of mmap in postgresql core and
extensions". You don't have to look further than the availability of
mmap to plperlu programmers to realize that that won't fly. (Even if
we threw all the untrusted PLs overboard, I believe plain old stdio
is willing to use mmap in many versions of libc.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-06-17 18:48:14 | Re: forcing a rebuild of the visibility map |
Previous Message | Robert Haas | 2016-06-17 18:42:57 | Re: Experimental dynamic memory allocation of postgresql shared memory |