From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:58:48 |
Message-ID: | 20100809205848.GA9408@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 09, 2010 at 02:16:47PM -0400, Robert Haas wrote:
> I believe I went back and reread
> the old threads on this topic and it seems like the sticking point as
> far as POSIX shm goes it that it lacks a readable equivalent of
> shm_nattch. I think it was proposed to use a small syv shm and then
> do the main shared memory arena with shm_open, but at that point you
> start to wonder you're messing around with at all.
About using a small sysV segment for nattach and allocating the rest
another way: the reason to do it is that "the other way" can be
anything other than sysV. Namely, sysV has pathetic default limits
whereas you can mmap() a few gig anonymously and the kernel won't bat
an eyelid.
Even if "the other way" didn't allow you to resize anything (which is
what people appear to be talking about here) the benefit of being able
to specify useful sizes of shared buffers without having to reconfigure
the kernel makes it (ISTM) worthwhile doing irrespective of anything
else.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-08-09 20:59:26 | grouping sets - updated patch |
Previous Message | Heikki Linnakangas | 2010-08-09 20:58:27 | Re: Synchronous replication |